From: vanthof (vant) 

Sent: Monday, July 31, 1995 11 :59 PM 

To: Tom Laidig [tau] 

Cc: hopper (Mark Hofmann); tbr (Tim B. Robinson); geert (Geert Rosseel); wampler (Kurt 

Wampler); albers (Daniel Albers); vanthof (Dave Van't Hot) 
Subject: Re: euterpe tapout? here we go... 


Tom Laidig [tau] writes: 

> 

>I just got buttonholed by Jack, Al, and Ann for an impromptu meeting 
>about euterpe tapeout, given the edict that we must have euterpe 
>silicon by Dec 31, I explained that euterpe, as it exists now, does 
>not meet the "compromise' design rule set developed last week, and I 
>estimated 3 months of layout work before it could be made to do so. 
> 

>Given this, Al and Ann agreed that the best move is to tape out the 
>baseplate layers (currently defined as 010-140 -- all but metals, SDEC, 
>and silicide) ASAP in their current form, and pressed me for an 
>estimate of how soon this could happen. I made the possibly rash 
> statement that I thought we might be able to tapeout the baseplate on 
>Aug 14. (Jack mentioned some 1- or 2-udr well-well and well-nactive 
> spacing violations, to which Al said "waive them' ) 

I'll check my lower layer fracture flow generation, but I think it's basically done, I 
think all we need to do is make sure the chip meets the rules. 


>After some argument, we settled on Sep 1 as the target date to tape out 
>the layers up through Ml (plus any more metals we can get out by then) , 
>with the remaining metal layers taping out promptly thereafter. 

According to what rules? If we are going to tape out euterpe to the current rule set, 
then I think we can do upto metall. if we are to meet the compromised set, then your 
estimate of 3 months is more accurate . 

Oh by the way, 'promptly', is that the 'new math* equivalent for time speak? ;-) 


>I hope I didn't commit (however tentatively I tried to do so) to 
^anything _too_ rash. My estimates were predicated on a lot of stuff I 
>don't know enough about, including, but surely not limited to: 
> 

> There's a frame that is ready, or very nearly so 
> 

> The only problems in the lower layers are the spacing violations 

> mentioned above 
> 

> We have few metal lvs and drc problems, perhaps limited to the short 

> found recently in the cache 
> 

> A pad, seal ring, crack protection ring, and perimeter power bus 

> that makes people happy can be developed in a timeframe never 

> before seen at this company (BTW, Al said basket weave perforation 

> in the pads would be fine) 
> 

>Anyway, like I say, I hope I didn't misrepresent things too badly. If 
>I did, feel free to blame me. Jack will be visiting some of you very 
>soon, I expect, to try to convince you all to agree to this. The 
> impression I have now is that taping out euterpe is our highest 
>priority, but I dunno -- the highest priority seems to change several 
>times a week as far as I can tell. 
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>Are we having fun yet? 
> 

Quick, someone get the tar. I'm sure Hopper can scrounge up a few rooster feathers.,. 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 40B 734-8100 dumb... just 

"I don't know the meaning of the word surrender' I mean, I Know ic, 
not in this context." The Tick to Thrackazog 
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From: 
Sent: 
To: 

Cc: 

Subject: 


tbr 

Monday, July 31, 1995 11:45 PM 
Daniel Albers 

geert@microunity.com; hopper@microunity.com; tau@microunity.com; Tom Laidig [tau]; 
vanthof@microunity.com; wampler@microunity.com 
Re: euterpe tapout? here we go... 


Daniel Albers wrote (on Mon Jul 31) : 

> the words of Tom Laidig [tau] : 
> 

> [snip] 
> 

> I hope I didn't commit (however tentatively I tried to do so) to 

> anything _too_ rash. My estimates were predicated on a lot of stuff I 

> don't know enough about/ including, but surely not limited to: 
> 

> There's a frame that is ready, or very nearly so 
> 

> [snippitte, snip, snip] 
> 

The frame is "nearly" ready. The one that is check' d in is completely 
wrong. But I believe I can have a good frame put together by the guestimated 
tapeout dates. 

Why does the frame need to be any different from the one (I assume) we have ready for 
pollux? 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Daniel Albers [albers@mlcrounity.com] 
Monday, July 31, 1995 11:11 PM 
Tom Laidig [tau] 

hopper@microunity.com; tbr@microunity.com; geert@microunity.com; 
vanthof@microunity.com; wampler@microunity.com] tau@microun'ity.com 
Re: euterpe tapout? here we go... 


> 


the words of Tom Laidig [tau] : 


> 


[snip] 


> 


> I hope I didn't commit (however tentatively I tried to do so) to 

> anything _too_ rash. My estimates were predicated on a lot of stuff I 

> don't know enough about, including, but surely not limited to: 


> [snippitte, snip, snip] 


The frame is "nearly" ready. The one that is check'd in is completely 
wrong. But I believe I can have a good frame put together by the guestimated 
tapeout dates. . . 


Daniel Albers albers@microunity.com MicroUnity Systems Engineering, inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 


"Evil is just plain bad! You don't cotton to it. You gotta smack it in the 
nose with the rolled-up newspaper of goodness! Bad dog! Bad dog!" 

- The Tick. 


> 


> 


There's a frame that is ready, or very nearly so 


> 


Dan 
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Subject: 


Sent: 
To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Monday, July 31, 1995 3:22 PM 
Tom Lafcfig [tau] 

tbr (Tim B. Robinson); geert (Geert Rosseel); vanthof (Dave Van't Hof); wampler (Kurt 
Wampler); albers (Daniel Albers); tau 
Re: euterpe tapout? here we go... 


Tom Laidig [tau] writes: 

I just got buttonholed by Jack, Al, and Ann for an impromptu meeting 
about euterpe tapeout, given the edict that we must have euterpe 
silicon by Dec 31. I explained that euterpe, as it exists now, does 
not meet the "compromise 1 design rule set developed last week, and I 
estimated 3 months of layout work before it could be made to do so. 

Given this, Al and Anh agreed that the best move is to tape out the 
baseplate layers (currently defined as 010-140 -- all but metals, SDEC, 
and silicide) ASAP in their current form, and pressed me for an 
estimate of how soon this could happen. I made the possibly rash 
statement that I thought we might be able to tapeout the baseplate on 
Aug 14, (Jack mentioned some 1- or 2-udr well-well and well-nactive 
spacing violations, to which Al said "waive them') 

After some argument, we settled on Sep 1 as the target date to tape out 
the layers up through Ml (plus any more metals we can get out by then) , 
with the remaining metal layers taping out promptly thereafter. 

I hope I didn't commit (however tentatively I tried to do so) to 
anything _too_ rash. My estimates were predicated on a lot of stuff I 
don't know enough about, including, but surely not limited to: 

There's a frame that is ready, or very nearly so 

The only problems in the lower layers are the spacing violations 
mentioned above 

We have few metal lvs and drc problems, perhaps limited to the short 
found recently in the cache 

A pad, seal ring, crack protection ring, and perimeter power bus 
that makes people happy can be developed in a timeframe never 
before seen at this company (BTW, Al said basket weave perforation 
in the pads would be fine) 

Anyway, like I say, I hope I didn't misrepresent things too badly. If 
I did, feel free to blame me. Jack will be visiting some of you very 
soon, I expect, to try to convince you all to agree to this. The 
impression I have now is that taping out euterpe is our highest 
priority, but I dunno -- the highest priority seems to change several 
times a week as far as I can tell. 

Are we having fun yet? 

Mondo Fun. 

I think 1 Sep is doable. J think 14 Aug is doable. Indeed (pick any date) is doable. Since 
we don't know all the things we need to do to make this chip work but we can make dark 
stabs at some I think the best course is to pick when we want something (31 Dec) and work 
backward. I think this is basically what was done. 

So, I have no problem with this. 

As to the question of which is higher priority- Euterpe or S2- I defer to the gods. 
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Brass tacks: 

It is therefore agreed to waive the SDEC/ISO problem (intersections)? 
Does everyone understand what pads we will use on Euterpe? 
Are we waffling poly/metal- I mean basket weave, slots, or ...? 
Are via layers not waffled, but Contact Ped is ? 

Let's pick a date and make it a hard date, I mean no fudging (since we are waiving rules 
already) and "just do it". 

-hopper 
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From: 
Sent: 
To: 

Subject: 


jack (Jack Wenstrand) 

Monday, July 31, 1995 10:18 PM 

tbn geert; manser; mouss; al; anh; torn 

Euterpe 


Here are notes from some Euterpe meetings today. 


tbr, manser, geert , mouss, jack 
2:30 


* A DRC check was run over the weekend on Euterpe. We 
are in much better shape than was thought; several 
cells have been cleaned up as a result of the Pollux 
reviews. We should be able to produce a Euterpe 
consistent with our current design rules- One 
exception: a 1 UDR active to well violation will remain. 

* The list of structures for review include, in 
priority order: 

a) Register file 

b) Pads 

c) Chip infrastructure (bias, clock, power 
distribution) 

d) PLL (required for bias) 

* Schedule constrains imply that: 

a) We cannot implement all of the compromise design 
rules . 

b) The lower level layouts must be ready for 
fracture by 9/25 . 

c) The upper level layouts must be ready by 
9/22 . 

* We should have Euterpe DRC clean and tape out all 
levels on 9/1. The second metal tape out can still 
occur; doing a full tape out first will cost some 
extra money, but it will maximize our chances of 
meeting the overall Euterpe schedule. 

* To continue progress, Steve will work resource 
allocation/plan to ensure Euterpe tapes out on 
schedule . 

* Jack will call a meeting tomorrow, to include Al, 
Anh, and Paul, to set priorities for work to 
maximize the probability of success on Euterpe 
within the schedule constraints. 

* Jack will talk to Al to set the stage for register 
file review tomorrow at 11. 

* Geert will continue progress on contract mask 
designers 


al, anh, torn, jack 


* The fab would prefer to have a Euterpe which meets 
compromise design rules. Failing that, they want 


7 pm 
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baseplate ASAP. This permits: 

- as much time as possible for fabrication in the 
event of unfavorable down- time events, and 

- the best shot at an extra turn. 

* Full implementation of the compromise design rules 
is inconsistent with schedule constraints. 

* A proposal for schedule is as follows : 

- baseplate (through 140) tapeout 8/14. 

- Ml tapeout 9/1, with the rest following ASAP. 

* Layout reviews should begin following on the 
baseplate work. Al would like to see the pad first. 

* Al prefers not to meet to set priorities for 
incremental design work at this time. 
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Cc: 

Subject: 


From: 
Sent: 
To: 


torn (Tom Laidig [tau]) 
Monday, July 31, 1995 10:04 PM 

hopper (Mark Hofmann); tbr (Tim B, Robinson); geert (Geert Rosseel); vanthof (Dave Van't 

Hof); wampler (Kurt Wampler); albers (Daniel Albers) 

tau 

euterpe tapout? here we go... 


I just got buttonholed by Jack, Al, and Anh for an impromptu meeting about euterpe 
tapeout, given the edict that we must have euterpe silicon by Dec 31. I explained that 
euterpe, as it exists now, does not meet the "compromise' design rule set developed last 
week, and I estimated 3 months of layout work before it could be made to do so. 

Given this, Al and Anh agreed that the best move is to tape out the baseplate layers 
(currently defined as 010-140 -- all but metals, SDEC, and silicide) ASAP in their current 
form, and pressed me for an estimate of how soon this could happen, I made the possibly 
rash statement that I thought we might be able to tapeout the baseplate on Aug 14. (Jack 
mentioned some 1- or 2-udr well -well and well-nactive spacing violations, to which Al said 
"waive them') 

After some argument, we settled on Sep 1 as the target date to tape out the layers up 
through Ml (plus any more metals we can get out by then) , with the remaining metal layers 
taping out promptly thereafter. 

I hope I didn't commit (however tentatively I tried to do so) to anything _too_ rash. My 
estimates were predicated on a lot of stuff I don't know enough about, including, but 
surely not limited to: 

There's a frame that is ready, or very nearly so 

The only problems in the lower layers are the spacing violations 
mentioned above 

We have few metal lvs and drc problems, perhaps limited to the short 
found recently in the cache 

A pad, seal ring, crack protection ring, and perimeter power bus 
that makes people happy can be developed in a timeframe never 
before seen at this company (BTW, Al said basketweave perforation 
in the pads would be fine) 

Anyway, like I say, I hope I didn't misrepresent things too badly. If I did, feel free to 
blame me. Jack will be visiting some of you very soon, I expect, to try to convince you 
all to agree to this. The impression I have now is that taping out euterpe is our highest 
priority, but I dunno -- the highest priority seems to change several times a week as far 
as I can tell. 

Are we having fun yet? 
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From: 
Sent: 
To: 

Subject: 


tbr 

Monday, July 31, 1995 7:59 PM 
vo (Tom Vo) 
RE: Now we got 2 


Tom Vo wrote (on Mon Jul 31) : 


Since tapeout means having a good tape in your hand , you're 
way ahead of me . With all the PCI bugs deepak and age 
found so far , we're in the pits . 

Does this mean there are more than the one known problem as of late last week? I'd not 
heard of any new ones. 

Congratulations . 

Thanks. But now we get to fix up the DRC 1 s (again) . 


Tim 
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From: vo (Tom Vo) 

Sent: Monday, July 31 , 1 995 2:05 PM 

To: tor (Tim B. Robinson) 

Subject: RE: Now we got 2 


Since tapeout means having a good tape in your hand , you're way ahead of me . With all 
the PCI bugs deepak and age found so far , we're in the pits . 

Congratulations . 
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From: vanthof (vant) 

Sent: Monday, July 31, 1995 12:12 AM 

To: Geert Rosseel 

Cc: hopper (Mark Hofmann); rich (Rich McCauley); tau; tbr (Tim B. Robinson); vanthof (Dave 

Van't Hot) 

Subject: Re: pollux : where to go from here ? 


Geert Rosseel writes: 


> Here is the status of pollux : 
> 

> LVS : clean 

Cooll I was worried that all the pad edits I did would screw something up. 


> CSYN : 5 errors : 4 we will waive { need csyn tool enhancements ) 

> 1 error in pll module needs investigating 
> 

> DRC : 2 "real" errors : GTLB active to well spacing 

> MOD 6 floating poly (arya needs to 

> investigate) 

I believe the active to well spacing is off by 1 udr (which is .05 microns). 
We may be able to get Al and Paul to waive this error this one time. 

Especially since we will most likely redraw most of this to meet the compromised drc rule 
set. 


> lot's of notch and different type of metal errors 


> I suggest that we : 
> 

> 1 . understand the pll csyn error 

> 2 . look at the mods floating poly 
> 

> and then freeze the database for tape- out . 

> 

> Any comments ? 


> Geert 

Sounds good if we can get the waiver on the gtlb error. 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 
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From: geert (Geert Rosseel) 

Sent: Sunday, July 30, 1995 2:04 PM 

To: geert@microunity,com; hopper 

Cc: rich; tau; tbr; vanthof 

Subject: Re: pollux : where to go from here ? 


Is the GTLB active to well spacing DRC a show-stopper? 

I don't know. I want to waive it. We've always said that if some modules are not perfect, 
we would tape -out anyway. This is such a case. 

Pollux pads are O.K. 

Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Sunday, July 30, 1995 6:36 AM 
Geert Rosseel 

rich (Rich McCauley); tau; tbr (Tim B. Robinson); vanthof (Dave Van't Hof) 
Re: pollux : where to go from here ? 


Geert Rosseel writes: 

Here is the status of pollux : 

LVS : clean 

CSYN : 5 errors : 4 we will waive ( need csyn tool enhancements ) 
For future work: is Pwo aware of what needs to be done here? 


DRC : 2 "real" errors : GTLB active to well spacing 

MOD 6 floating poly (arya needs to investigate) 

lot's of notch and different type of metal errors 


I suggest that we : 

1. understand the pll csyn error 

2. look at the mode floating poly 

and then freeze the database for tape-out . 
Any comments ? 

Is the GTLB active to well spacing DRC a show-stopper? Do you want to waive that? 

Do any of the Pollux pads need extra massaging for tapeout (Probably to a flow like that 

used on Sisyphus I)? 

If we can convince Al/Paul into accepting the die as it stands as a test vehicle for fab 
use then I think we should go ahead with it. 


1 error in pll module needs 


investigating 


Geert 


-hopper 
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From: geert (Geert Rosseel) 

Sent: Sunday, July 30, 1995 1:28 PM 

To: hopper; rich; tau; tbr; vanthof 

Subject: pollux : where to go from here ? 


Here is the status of pollux : 
LVS : clean 

CSYDT : 5 errors : 4 we will waive ( need csyn tool enhancements ) 
1 error in pll module needs investigating 

DRC : 2 "real" errors : GTLB active to well spacing 

MOD 6 floating poly (arya needs to investigate) 

lot 1 s of notch and different type of metal errors 


I suggest that we : 

1. understand the pll csyn error 

2. look at the mode floating poly 

and then freeze the database for tape- out . 
Any comments ? 


Geert 
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Subject: 


From: 
Sent: 
To: 

Cc: 


hopper (Mark Hofmann) 
Saturday, July 29, 1995 3:56 PM 
Tim B. Robinson 
vant; wampler@microunity.com 
Re: IGHzeuterpe 


Tim B . Robinson writes : 

Will removing these qualifiers reduce the routing success rate any? 

Don't think so. This runs after the route is complete. 

Kurt confirmed that . 

Now, if we can just arrive at a set of tape- out synthesis rules that 
don't invalidate our layout, but that the Fab can build, we could well 
see functioning parts. Al mentioned Friday that they had done an early 
2-layer airbridge experiment that looked promising. I haven't seen the 
SEM photos yet, but hope to on Monday. 

I think this is the focus of our next effort. As quickly as we can we need to 
converge on a set of tapeout rules so that Dave can turn these into a 
flow so that we can process Euterpe. Then we need to snapshot this rule flow to 
which we are taping out this set of euterpe masks, so that we can refer to 
it when questions arise at a later date. 

We should snapshot technology. Do we need tools too? 

I think the technology snapshot is sufficient. Tools would be nice, though. 


^hopper 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tbr 

Saturday, July 29, 1995 9:44 PM 
hopper (Mark Hofmann) 
vant; Kurt Wampler 
Re: IGHzeuterpe 


Mark Hofmann wrote (on Sat Jul 29) : 
Kurt Wampler writes: 
tbr writes : 


>You did it: 

>********** Iteration: 1 ********** 
>********** dc Load Calculations ********** 
>No errors at 1GHz !!!!!! 
> 

>We just need to get the DC load problems signed off. . . 

Fantastic! A team effort, to be sure. Too bad Bill z. didn't stick around 
to see it reach this milestone. 

It would be appropriate to copy this dff into the snapshot and re- run the 
export rule in the Makefile before we launch the LVS , I would also like 
to recommend that we remove the " -vlh" and "~v2h" qualifiers on the 
twinvia pass in "Makef ile . vo" . These are soft constraints that cause 
the twinner to always try to place vias horizontally; this reduces its 
success rate slightly. I don't have a very up-to-date copy of the 
Euterpe source tree checked out, so it would be better for you to make 
and release this change before re-running the export. 

Will removing these qualifiers reduce the routing success rate any? 

Don't think so. This runs after the route is complete. 

Now, if we can just arrive at a set of tape -out synthesis rules that 
don't invalidate our layout, but that the Fab can build, we could well 
see functioning parts. Al mentioned Friday that they had done an early 
2- layer airbridge experiment that looked promising. I haven't seen the 
SEM photos yet, but hope to on Monday. 

I think this is the focus of our next effort. As quickly as we can we need to 

converge on a set of tapeout rules so that Dave can turn these into a 

flow so that we can process Euterpe. Then we need to snapshot this rule flow to 

which we are taping out this set of euterpe masks, so that we can refer to 

it when questions arise at a later date. 

We should snapshot technology. Do we need tools too? 


Tim 
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From: tbr 

Sent: Saturday, July 29, 1995 9:42 PM 

To: wampler (Kurt Wampler) 

Cc: hopper 

Subject: Re: IGHzeuterpe 


Kurt Wampler wrote (on Sat Jul 29) : 
tbr writes : 


>You did it: 

>********** iteration: 1 ********** 
>********** DC Load Calculations ********** 


>No errors at 1GHz I J ! ! J ! 
> 

>We just need to get the DC load problems signed off . . . 

Fantastic 1 A team effort, to be sure. Too bad Bill Z. didn't stick around 
to see it reach this milestone . 

It would be appropriate to copy this dff into the snapshot and re -run the 
export rule in the Makefile before we launch the LVS . I would also like 
to recommend that we remove the n -vlh" and "-v2h n qualifiers on the 
twinvia pass in "Makef ile . vo" . These are soft constraints that cause 
the twinner to always try to place vias horizontally; this reduces its 
success rate slightly. I don't have a very up-to-date copy of the 
Euterpe source tree checked out, so it would be better for you to make 
and release this change before re-running the export. 

Releasing now. 

Now, if we can just arrive at a set of tape-out synthesis rules that 
don't invalidate our layout, but that the Fab can build, we could well 
see functioning parts. Al mentioned Friday that they had done an early 
2-layer airbridge experiment that looked promising. I haven't seen the 
SEM photos yet, but hope to on Monday. 

Sounds promising. 

Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


hopper (Mark Hofmann) 
Saturday, July 29, 1995 12:01 PM 
Kurt Wampler 
tbr (Tim B. Robinson); vant 
Re: IGHzeuterpe 


Kurt Wampler writes: 
tbr writes: 


>You did it: 

>********** iteration: 1 ********** 
>********** dc Load Calculations ********** 
>No errors at 1GHz! ! ! ! i ! 
> 

>We just need to get the DC load problems signed off . . . 

Fantastic! A team effort, to be sure. Too bad Bill Z. didn't stick around 
to see it reach this milestone. 

It would be appropriate to copy this dff into the snapshot and re -run the 
export rule in the Makefile before we launch the LVS. I would also like 
to recommend that we remove the " -vlh" and n -v2h" qualifiers on the 
twinvia pass in "Makef ile . vo n . These are soft constraints that cause 
the twinner to always try to place vias horizontally; this reduces its 
success rate slightly. I don't have a very up-to-date copy of the 
Euterpe source tree checked out, so it would be better for you to make 
and release this change before re-running the export. 

Will removing these qualifiers reduce the routing success rate any? 

Now, if we can just arrive at a set of tape -out synthesis rules that 
don't invalidate our layout, but that the Fab can build, we could well 
see functioning parts. Al mentioned Friday that they had done an early 
2 -layer airbridge experiment that looked promising. I haven't seen the 
SEM photos yet, but hope to on Monday. 

I think this is the focus of our next effort. As quickly as we can we need to converge on 
a set of tapeout rules so that Dave can turn these into a flow so that we can process 
Euterpe. Then we need to snapshot this rule flow to which we are taping out this set of 
euterpe masks, so that we can refer to it when questions arise at a later date. 

- Kurt 

-hopper 


-thanks, 
hopper 


thanks , 
mark hofmann 
hopperOmicrounity . com 
408 734 8100 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 
Saturday, July 29, 1995 6:55 PM 
tbr 

hopper 

Re: IGHzeuterpe 


tbr writes: 


>You did it: 

>********** Iteration: 1 ********** 

>********** dc Load Calculations ********** No errors at lGHz!!!!!J 
> 

>We just need to get the DC load problems signed off . . . 

Fantastic! A team effort, to be sure. Too bad Bill Z. didn't stick around 
to see it reach this milestone. 

It would be appropriate to copy this dff into the snapshot and re -run the 
export rule in the Makefile before we launch the LVS . I would also like 
to recommend that we remove the " -vlh" and ,l -v2h 1 ' qualifiers on the 
twinvia pass in "Makef ile . vo" . These are soft constraints that cause 
the twinner to always try to place vias horizontally; this reduces its 
success rate slightly. I don't have a very up-to-date copy of the 
Euterpe source tree checked out, so it would be better for you to make 
and release this change before re-running the export. 

Now, if we can just arrive at a set of tape-out synthesis rules that 
don't invalidate our layout, but that the Fab can build, we could well 
see functioning parts. Al mentioned Friday that they had done an early 
2-layer airbridge experiment that looked promising. I haven't seen the 
SEM photos yet, but hope to on Monday. 


- Kurt 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tbr 

Saturday, July 29, 1995 2:23 PM 

wampler (Kurt Wampler) 

dickson 

Re: bad paths 


Kurt Wampler wrote (on Sat Jul 29) : 


tbr writes: 


>Get these 2 and we are done! There are some D load problems and I 

>want a sign off from geert/bill on those. 

> 

> [snip] 


OK, I've mucked around in the last 2 paths. On the first one, I found 
that one of the nets had a number of M2 segments that I was able to promote 
to M4; should be enough to shave off 1.52ps. 

On the second one, I found a hairpin maze route on M2 that took a very 
circuitous path between two nearby pins. I blew away the whole route 
and completed it in M3/M4; should have improved that leg substantially. 

Same file as before: /n/gamorra/s3/wampler/eurip/chip_euterpe- iter . df f 

Maybe it'll meet timing this time? My fingers are crossed... 

Sorry, I was out for a while. Running now. 


[P.S. - just a subjective observation: this route is a lot better than the 
routes I was working on in April where I would spend hours trying to find 
a way to complete a wire in some of the more dense sections. None of the 
wires I've operated on in this tuning operation were anywhere near as 
difficult as some of those early experiences. By this, I infer that you've 
made *dramatic* improvements with the placement.] 

Actually I think most of the improvement has come from single ending more busses, rather 
than much in the way of placement changes. Most of that work is really rich's doing. I 
think I've made significant improvements from a timing perspective by playing with the 
detail so of the routing order. 


- Kurt 
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From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 
Saturday, July 29, 1995 1:29 PM 
tbr 

Re: bad paths 


tbr writes: 


>Get these 2 and we are done ! There are some r> load problems and I want 
>a sign off from geert/bill on those. 


OK, I've mucked around in the last 2 paths. On the first one, I found 
that one of the nets had a number of M2 segments that I was able to promote 
to M4; should be enough to shave off l.52ps. 

On the second one, I found a hairpin maze route on M2 that took a very- 
circuitous path between two nearby pins. I blew away the whole route 
and completed it in M3/M4; should have improved that leg substantially. 

Same file as before: /n/gamorra/ s3/ wampler /eurip/chip_euterpe- iter . dff 

Maybe it'll meet timing this time? My fingers are crossed... 


[P.S. - just a subjective observation: this route is a lot better than the routes I was 
working on in April where I would spend hours trying to find a way to complete a wire in 
some of the more dense sections. None of the wires I've operated on in this tuning 
operation were anywhere near as difficult as some of those early experiences. By this, I 
infer that you've made *dramatic* improvements with the placement.] 


> 


> [snip] 


- Kurt 


Exhibit C16 


Page 22 of 12 


Subject: 


Sent: 

To: 

Cc: 


From: 


tbr 

Saturday, July 29, 1995 10:19AM 
wampler (Kurt Wampler) 
dickson; geert 
Euterpe bad route fixes 


Kurt Wampler wrote (on Sat Jul 29) : 
Good morning, 

I have finished going through the paths with timing violations, and have 
shortened all of them, I think. The file: 

/n/gamorra/s3 /wampler /eurip/chip_euterpe- iter . df f 

now contains these improvements. There's a new netcap file; I've verified 
that the total capacitance went down for everything I touched, some more 
dramatically than others. 

Could you have another go with topt and we ' 11 see if by some miracle I got 
enough wire length out to meet the timing budget? 

2 paths exceeded cycle time !!!! 

Should have the details in a moment. 

Tim 
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From: 
Sent: 
To: 

Subject: 


for 

Saturday, July 29, 1995 9:37 AM 
wampler (Kurt Wampler) 
Euterpe bad route fixes 


Kurt Wampler wrote (on Sat Jul 29) : 
Good morning/ 

I have finished going through the paths with timing violations, and have 
shortened all of them, I think- The file: 

/n/gamorra/ s3 /wampler /eurip/chip_euterpe- iter .dff 

now contains these improvements. There's a new netcap file; I've verified 
that the total capacitance went down for everything I touched, some more 
dramatically than others. 

Could you have another go with topt and we'll see if by some miracle I got 
enough wire length out to meet the timing budget? 

I'll start it up now. 

Tim 
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From: 
Sent: 
To: 

Subject: 


wampler (Kurt Warn pier) 
Saturday, July 29, 1995 2:53 AM 
tbr 

Euterpe bad route fixes 


Good morning, 

I have finished going through the paths with timing violations, and have shortened all of 
them, I think. The file: 

/n/gamorra/ s3 /wampler /eurip/chip_euterpe- iter . df f 

now contains these improvements. There's a new netcap file; I've verified that the total 
capacitance went down for everything I touched, some more dramatically than others. 

Could you have another go with topt and we'll see if by some miracle I got enough wire 
length out to meet the timing budget? 


- Kurt 
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From: tbr 

Sent: Friday, July 28, 1 995 1 1 :20 PM 

To: vanthof (vant) 

Cc: geert (Geert Rosseel); tau; Tom Laidig [tau]; vanthof (Dave Van't Hof); wampler (Kurt 

Wampler) 

Subject: Re: looking for euterpeJy 


vant wrote (on Fri Jul 28) : 

Tom Laidig [tau] writes: 
> 

>I'm looking for the most up-to-date euterpe.ly to get a list of layouts 
>that need to be released. The one in the snapshot doesn't seem very 
>new: 
> 

> 61 -rw-r--r~- 1 chip caddev 62038 Apr 17 12:01 euterpe.ly 

> 

>Dave said there was one in -vanthof /compass /mobi/euterpe/tapeout, but a 
>"find T failed to find a file called euterpe.ly anywhere under 
>~vanthof /compass . 
> 

>For the moment, I'm using the one in the snapshot to get my cell list. 
>If anyone has a better one, I'll use it. 

Sorry, I mis-stated what I meant to say. There is a euterpe.ly found in the 
search path specified in the vlsi.boo found in that directory. 

The latest one is now: 


0 -rw-r--r-- 1 chip 0 Jul 28 20:02 chip euterpe- iter . ly 

1 -rw-r--r-- 1 chip 646 Jul 28 20:02 rbaseplate . ly 
61 -rw-r--r-- 1 chip 62038 Jul 28 20:02 euterpe.ly 

18 -rw-r--r-- 1 chip 17795 Jul 28 20:02 real_euterpetop . ly 

35 drwxr-xr-x 2 chip 35328 Jul 28 20:10 . 

tbr@staypuft /n/auspex/s4l/euterpe-snapshot/euterpe/compass/baseplate 24 % 

I have no idea if this is good, but the make appeared to run without error to generate it. 
Tim 
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From: vanthof (vant) 

Sent: Friday, July 28, 1 995 1 0:51 PM * 

To: Tom Laidig [tau] 

Cc: tbr (Tim B. Robinson); wampler (Kurt Wampler); geert (Geert Rosseel); tau; vanthof (Dave 

Vant Hof) 

Subject: Re: looking for euterpe.ly 


Tom Laidig [tau] writes: 
> 

>I'm looking for the most up-to-date euterpe.ly to get a list of layouts 
>that need to be released. The one in the snapshot doesn't seem very 
>new: 
> 

> 61 -rw-r--r-- 1 chip caddev 62 038 Apr 17 12:01 euterpe.ly 

> 

>Dave said there was one in ~vanthof/ compass /mobi/euterpe/t apeout , but a 
>"find 1 failed to find a file called euterpe.ly anywhere under 
>~vanthof /compass . 
> 

>Por the moment, I'm using the one in the snapshot to get my cell list. 
>If anyone has a better one, I'll use it. 

Sorry, I mis-stated what I meant to say. There is a euterpe.ly found in the search path 
specified in the vlsi.boo found in that directory. 

Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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Sent: 

To: 

Cc: 


Subject: 


From: 


jack (Jack Wenstrand) 
Friday, July 28, 1995 7:33 PM 
manser; tbr; geert 
mouss; tony 
Euterpe 


Minutes 

Euterpe meeting 
7/28/95 

Attending: Geert, Tim, Steve, Jack 
Topic: Layout reviews for Euterpe, 
Notes : 

Euterpe lower levels must tape out by 9/1. The 
fracture flow must begin on 8/24. Thus, we have 
less than 4 weeks for layout adjustments. 

The current Euterpe is in an intermediate state 
between the last set of design rules and the 
current one. 

Many Pollux cells flow directly into Euterpe, are 
consistent with the current design rules, and have 
recently been reviewed by the fab organization. 

More important areas for review include: 
Clock 
Bus 

Register file 

Cerberus 

Pads 

Actions : 

Geert will pull in all the latest Euterpe cells and 
start a DRC over the weekend. 

Tim will put together a prioritized list of cells 
for review by the fab organization, to be discussed 
at 2:30 on Monday . 

Jack will speak with Anh and Al about Euterpe on 
Monday . 

Steve, Geert, Tim, and Jack will meet to followup on 
Tuesday. 
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Sent: 

To: 

Cc: 


Subject: 


From: 


for 

Friday, July 28, 1995 7:26 PM 
torn (Tom Laidig [tail]) 

geert (Geert Rossee!); tau; vanthof (Dave Van't Hof); warn pier (Kurt Wampler) 
looking for euterpe.ly 


Tom Laidig [tau] wrote (on Fri Jul 28) : 


I'm looking for the most up-to-date euterpe.ly to get a list of layouts 
that need to be released. The one in the snapshot doesn't seem very 
new: 


61 -rw-r- -r- - l chip 


caddev 


62 038 Apr 17 12:01 euterpe.ly 


Dave said there was one in -vanthof /compass /mobi/euterpe /tapeout, hut a 
"find' failed to find a file called euterpe.ly anywhere under 
-vanthof /compass . 

For the moment, I'm using the one in the snapshot to get my cell list. 
If anyone has a better one, I'll use it. 

I'm going to generate a new one in the snapshot off the route kurt has 
just completed. I have no idea what the origin is of the one that's 

there now. It's not been generated automatically off the flow because the route/timing 
does not complete 100% without manual intervention. 


Tim 
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From: torn (Tom Laidig [tau]) 

Sent: Friday, July 28, 1 995 6:38 PM 

To: tbr (Tim B. Robinson); wampler (Kurt Wampler); vanthof (Dave Van't Hof); geert (Geert 

Rosseel) 
Cc: tau 
Subject: looking for euterpe.ly 


I'm looking for the most up-to-date euterpe.ly to get a list of layouts that need to be 

released. The one in the snapshot doesn't seem very 

new: 


61 -rw-r--r-- 1 chip caddev 62038 Apr 17 12:01 euterpe.ly 

Dave said there was one in -vanthof /compass /mobi/euterpe/ tapeout, but a "find' failed to 
find a file called euterpe.ly anywhere under -vanthof /compass . 

For the moment, I'm using the one in the snapshot to get my cell list. 
If anyone has a better one, I'll use it. 
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Subject: 


From: 
Sent: 
To: 


graham (Graham Y. Mostyn) 
Friday, July 28, 1995 6:04 PM 

abbott@gaea; bill@gaea; craig@mnemosyne; geert@gaea; gmo@gaea; graham@gaea; 
hayes@gaea; lisar@gaea; mudge@gaea; tbr@gaea; manser@charybdis 
Re: Input Please 


1) Hestia 


Regarding Hestia, a second revision of the main circuit board and also the bandsplit 
daughter board were recently received and tested. 

The most significant problem on the main board - upstream transmitter stability - has been 
solved. The new transmit circuit layout is completely stable. 

The bandsplit board has had 14 components eliminated, is much more manuf acturable (through 
hole and surface mount components have been isolated on different sides) , and the RF loss 
is greatly reduced to only - ldB, within spec. 

The boards cannot be fully debugged without Euterpe /Calliope, but in the absence of those 
chips, the progress of design, evaluating the first revision, and successfully correcting 
the major problems on this version justify recognition. 

2) Cablemodem RFP 

I think that the intensive effort and significant innovation on the CableLabs cablemodem 
RFP - and the CMAC protocol developed - deserve mention. 


> From manser@charybdis Wed Jul 2 6 19:39:25 1995 

> Date; 26 Jul 1995 19:37:24 -0800 

> From: "manser" <manser@charybdis> 

> Subject: Input Please 

> To: "abbott" < abbot t@gaea > , "bill" <bill@gaea>, "craig" < crai gOmnemosyne > , 

> "geert" <geert@gaea>, "gmo" <gmo@gaea>, "graham" <graham@gaea> , 

> "hayes" <hayes@gaea>, "lisar" <lisar@gaea>, "mudge" <mudge@gaea>, 

> " tbr " < tbrOgaea > 

> Cc : manser@charybdis 

> Content -Length: 1384 
> 

> As you heard today at company lunch, we will be having a 

> communications meeting next Wednesday. As part of this, I'd like to 

> solicit input for examples of progress to be recognized (at the team level) . 
> 

> Here is a partial list of (near) accomplishments over the last few weeks: 
> 

> - working oscillators (3 level metal) 
> 

> - working Sisyphus CMOS and B I CMOS ring oscillators 
> 

> - (near) clean Pollux design (this may be done by the end of this 

> week) 
> 

> - Mnemo is currently fully routed and timing accurate. However there are 

> some logic fixes which need to be completed and rerouted/ timed. Again, 

> this should be done prior to first Friday. 

> 

> - Euterpe is nearly completed. No known logic bugs, only another 40-50 

> routes and timing paths need to be completed. Again, this should be 

> do-able by FF. 


Graham . 


> 
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> - OSF running on software simulator (not to prompt yet) . This 

> validates the 

> compiler and OSF port. 
> 

> - Others .. .Hestia, Pandora, etc. We will need to make sure we 

> don't miss any 

> major milestones across the company. 

> 
> 

> Please provide me with your feedback by Friday on two subjects: 
> 

> 1 Am I missing any areas (I apologize in advance) ? 
> 

> 2 When will we know if we have 100% success for those areas where we 

> are close (Unix prompt , Euterpe routes, etc.)? Alternately, we can 

> always get an update on Tuesday night to finalize. 

> 

> Steve 
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From: 
Sent: 
To: 

Subject: 


graham (Graham Y. Mostyn) 
Friday, July 28, 1995 6:04 PM 

abbott@gaea; bill@gaea; craig@mnemosyne; geert@gaea; gmo@gaea; graham@gaea; 
hayes@gaea; lisar@gaea; mudge@gaea; tbr@gaea; manser@charybdis 
Re: Input Please 


1) Hestia 

Regarding Hestia, a second revision of the main circuit board and also the bandsplit 
daughter board were recently received and tested. 

The most significant problem on the main board - upstream transmitter stability - has been 
solved. The new transmit circuit layout is completely stable. 

The bandsplit board has had 14 components eliminated, is much more manuf acturable (through 
hole and surface mount components have been isolated on different sides) , and the RF loss 
is greatly reduced to only - ldB, within spec. 

The boards cannot be fully debugged without Euterpe /Calliope, but in the absence of those 
chips, the progress of design, evaluating the first revision, and successfully correcting 
the major problems on this version justify recognition. 

2) Cablemodem RFP 

I think that the intensive effort and significant innovation on the CableLabs cablemodem 
RFP - and the CMAC protocol developed - deserve mention. 

Graham . 


> From manser@charybdis Wed Jul 26 19:39:25 1995 

> Date: 26 Jul 1995 19:37:24 -0800 

> From: "manser" <manser@charybdis> 

> Subject: Input Please 

> To: "abbott" <abbott@gaea>, "bill" <bill@gaea>, "craig" <craig@mnemosyne> , 

> "geert" <geert@gaea>, "gmo" <gmo@gaea>, "graham" <graham@gaea> , 

> "hayes" <hayes@gaea>, "lisar' r <lisar@gaea>, "mudge" <mudge@gaea>, 

> "tbr" <tbr@gaea> 

> Cc : manser@charybdis 

> Cont ent - Length : 1384 
> 

> As you heard today at company lunch, we will be having a 

> communications meeting next Wednesday. As part of this, I'd like to 

> solicit input for examples of progress to be recognized (at the team level) . 
> 

> Here is a partial list of (near) accomplishments over the last few weeks: 
> 

> - working oscillators (3 level metal) 
> 

> - working Sisyphus CMOS and B I CMOS ring oscillators 
> 

> - (near) clean Pollux design (this may be done by the end of this 

> week) 
> 

> - Mnemo is currently fully routed and timing accurate. However there are 

> some logic fixes which need to be completed and rerouted/ timed. Again, 

> this should be done prior to first Friday. 
> 

> - Euterpe is nearly completed. No known logic bugs, only another 40-50 

> routes and timing paths need to be completed. Again, this should be 

> do- able by FF. 
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> - OSF running on software simulator (not to prompt yet) . This 

> validates the 

> compiler and OSF port . 
> 

> - Others. . -Hestia, Pandora, etc. We will need to make sure we 

> don't miss any 

> major milestones across the company. 


> Please provide me with your feedback by Friday on two subjects: 
> 

> 1 Am I missing any areas (I apologize in advance)? 
> 

> 2 When will we know if we have 100% success for those areas where we 

> are close (Unix prompt, Euterpe routes, etc .) ? Alternately, we can 

> always get an update on Tuesday night to finalize. 
> 

> Steve 
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Sent: 

To: 

Cc: 


From: 


graham (Graham Y. Mostyn) 
Friday, July 28, 1995 4:15 PM 
craig; manser; tbr; tony; todd 
graham; abbott 


Subject: 


Minutes - Zeus marketing 


Attendees: Craig Graham Tim Todd Tony Steve: 7/27/95 

Todd presented a set of slides which: 

- showed an example business objective for Zeus 

- provided a systematic methodology for analysing and ranking application opportunities, 
and combining them with a value proposition 

- included proposed sources of value and market positioning for Zeus, with potential 
application opportunities. 

The following minutes should be read in conjunction with the slides, both of which will be 
entered on-line: 

1. The business objective statement presented on the slide example was discussed. The 
following were also raised: 

- power efficient 

- a real product, not a demonstrator 

- revenue is largely licensing 

- company visibility and technology leadership important 

- diffuse the architecture 

- complementary product to Mobi equivalent and Euterpe 

While Zeus will most likely represent a family of products, the implementation as a 
"core" is an important one, and places restrictions on die size, since the customer will 
wrap custom processing and I/O around it. 

We need to sharpen this statement of objective further. 

2. Product positioning. 
Comparing Zeus to microprocessors, 

programmable DSPs, custom ASICs and commodity signal processors (ASSPs) , we determined 
that Zeus offers signal processing capability over uPs, and is much easier to program than 
DSPs , where tools are currently poor. 

3. industry attractiveness/value proposition methodology. 

Given the provisos that we should project the conditions prevalent in the industry 18 - 24 
months ahead, we agreed to use the Porter methodology as an industry analysis tool, and 
write value propositions for selected applications. 

4. Comments on platforms 

There was general agreement to focus on products where our costs were comparable to ASICs, 

but the need to run software on the product gave us an advantage. 

Attractive applications were established ones of medium volume and high price. 

5. Applications listing 

We agreed to add "Data Switching" to those shown on our slide. 

6. Action items for the next meeting: 

* Tony committed to complete market sizes and growth rates for a set of presented 
applications; and additionally to project pricing/performance of MVPs and uPs 2 years 
ahead . 

* Craig agreed to analyse the PC market, using our methodology. 

* Participants were asked to select other preferred applications, and employ the analysis 
methodology. 

Next meeting: 

Thursday 3:30 pm August 3, Hardware Engineering Conf room 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Friday, July 28, 1995 1:14 AM 
Tim B. Robinson 

vanthof (Dave Van't Hof); geert (Geert Rosseel) 
Re: euterpe 


Tim B. Robinson writes: 
> 

>Ac cording to Ann, sisyphusl, pollux, sisyphus2, euterpe. She also 
>wants a revised calliope, but that's out for lots of non fab reasons. 

This is contrary to the statements Al made in a meeting yesterday where we hashed out the 
compromised design rule set. What he talked about was: 

sisyphusl , sisyphus2, pollux, euterpe 

>Clearly from our pespective pollux should go before euterpe, but I (and 
>geert and steve manser) are all very keen to get a euterpe that has no 
>known logic bugs (done) , csyn clean (done) , is fully routed (done) , 
>makes timing (will be done in a day or so) , and is LVS clean. 
>Then it's up to the fab to stop changing the rules. In the discussion 
>I had Anh was very strongly implying that they wanted it but was also 
>implying we were incapable of delivering it. I share your frustration. 
>However, I think things are improving a little. 


Well, nothing will go out until I get the tapeout flow updated to the latest rules and Tom 
gets vlsimm enhanced. By that time, sisyphys2 will be ready and we already know that the 
current pollux has structures that Al doesn't like and wants changed. 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb. . . just 
not in this context . " The Tick to Thrackazog 


>Tim 


Dave 
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Sent: 
To: 

Cc: 


Subject: 


From: 


tbr 

Friday, July 28, 1995 1:06 AM 
vanthof (vant) 

geert (Geert Rosseel); vanthof (Dave Van't Hof) 
Re: euterpe 


vant wrote (on Thu Jul 27) : 


Tim B. Robinson writes: 


> 


> 


>In a discussion with anh this afternoon she indicated great eagerness 
>to get a euterpe mask set to the same DRC rules as pollux. Is this 
consistent with what al is saying? Can we "go for it" while we have a 
> chance? 


>Tim 


> 


Bizarre. According to what I've heard, (well, one of a dozen different 
stories from the fab...) is that pollux will not work unless we redo the 
layouts to the compromized design rule set. Even that may not work and we 
won't know that until sisyphus2 is back. My impression from Al is that 
everything is keyed on the results of sisyphus2 . 

I hate to say this, that this whole situation is extremely frustrating. I 
can not get a straight answer about what chip set the fab wants to see. Is 
it sisyphus2? pollux, euterpe? in what order, and to what design rule set? 
Al claims any chip taped out to the current rules won't work, yet Ahn wants 
a euterpe? 

Sorry, I don't have the foggiest idea where to put my efforts? I'm getting 
very tired of putting lots of effort into the latest hot topic only to find 
out much later that virtually moments later, the focus has shifted and I've 
wasted my time. This will be the third time that I've done the backend 
flow, and it won't be the last. I really need a consistent set of answers. 

According to Anh, sisyphusl, pollux, sisyphus2, euterpe. She also wants a revised 
calliope, but that's out for lots of non fab reasons. 

To answer your question. Euterpe is probably weeks away from being drawn 
to the r pollux' standard. Almost all effort has gone into fixing up pollux. 
There are many areas which have not been looked at in euterpe. In addition, 
the entire pad ring is most likely still wrong amd must be redone, again. 

Unfortunately, we cannot 'go for it' just yet as there is probably a week 
or two worth or work for me to get the backend tapeout flow updated to the 
1 latest ' set of rules that Al and supposedly Ahn wants {which by the way, 
changed again today. . .) . In addition, Tom has quite a bit of work in 
vlsimmm just to get some mandatory enhancements in to meet the 'pollux' 
design rules. 

I'm expecting that by the time sisyphus2 layouts are done, I'll be ready, 
just in time, with the tapeout flow due to constant interruptions and 
meetings. No other chips can tapeout until this is done. 

Clearly from our pespective pollux should go before euterpe, but I (and geert and steve 
manser) are all very keen to get a euterpe that has no known logic bugs (done) , csyn clean 
(done) , is fully routed (done) , makes timing (will be done in a day or so) , and is LVS 
clean. 

Then it's up to the fab to stop changing the rules. In the discussion I had Anh was very 
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strongly implying that they wanted it but was also implying we were incapable of 
delivering it. I share your frustration. However, I think things are improving a little. 

Tim 
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From: vanthof (vant) 

Sent: Friday, July 28, 1995 12:53 AM 

To: Tim B. Robinson 

Cc: vanthof (Dave Van't Hof); geert (Geert Rosseel) 

Subject: Re: euterpe 


Tim B. Robinson writes: 

> 

> 

>In a discussion with anh this afternoon she indicated great eagerness 
>to get a euterpe mask set to the same DRC rules as pollux. Is this 
>consistent with what al is saying? Can we "go for it" while we have a 
> chance? 
> 

>Tim 


Bizarre. According to what I've heard, {well, one of a dozen different stories from the 
fab. is that pollux will not work unless we redo the layouts to the compromized design 
rule set. Even that may not work and we won't know that until sisyphus2 is back. My 
impression from Al is that everything is keyed on the results of sisyphus2 . 

I hate to say this, that this whole situation is extremely frustrating. I can not get a 
straight answer about what chip set the fab wants to see. Is it sisyphus2? pollux, 
euterpe? in what order, and to what design rule set? 

Al claims any chip taped out to the current rules won't work, yet Ahn wants a euterpe? 

Sorry, I don't have the foggiest idea where to put my efforts? I'm getting very tired of 
putting lots of effort into the latest hot topic only to find out much later that 
virtually moments later, the focus has shifted and I've wasted my time. This will be the 
third time that I've done the backend flow, and it won't be the last. I really need a 
consistent set of answers. 

To answer your question. Euterpe is probably weeks away from being drawn to the 'pollux' 
standard. Almost all effort has gone into fixing up pollux. 

There are many areas which have not been looked at in euterpe. In addition, the entire 
pad ring is most likely still wrong amd must be redone, again. 

Unfortunately, we cannot 'go for it' just yet as there is probably a week or two worth or 
work for me to get the backend tapeout flow updated to the 'latest 1 set of rules that Al 
and supposedly Ahn wants {which by the way, changed again today. ..} . In addition, Tom has 
quite a bit of work in vlsimmm just to get some mandatory enhancements in to meet the 
'pollux' 
design rules. 

I'm expecting that by the time sisyphus2 layouts are done, I'll be ready, just in time, 
with the tapeout flow due to constant interruptions and meetings. No other chips can 
tapeout until this is done. 

Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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From: geert (Geert Rosseel) 

Sent: Thursday, July 27, 1 995 9: 1 9 AM 

To: poilux 

Subject: poilux LVS clean 


Hi, 

The toplevel Pollux is LVS clean. 

We will spend a couple of days fixing up DRC errors and tape out . 
There are three top-level csyn problems. I will send a mail on this later. 

Geert 
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From: wingard (Drew Wingard) 

Sent: Thursday, July 27, 1995 12:48 AM 

To: steve 

Cc: geert; jack; manser; tbr 

Subject: Re: FW: Imminent Decision: Cronus die size 


Steve Brown wrote: 

> Drew, 

> A die this large may reduce schedule risk but it may only yield 1 good 

> die per 6" TSMC wafer and 7 good die per 8" CSM wafer. How do you 

> trade off the schedule risk with the low/no yield risk? 
> 

> Maybe Jack has newer data on yield. 
> 

> Thanks. 

The yield risk is real, but it is not as if we 1 re moving from a high-yield place to a low 
one. We always knew that this was a low-yield design in these processes. The latest 
decision is more a reflection of trying to avoid a 6+ month physical design exercise (that 
would not yield a compelling product, and which would unacceptably delay our software and 
system bring-up activities) . 

I would term this die size decision as a calculated risk. We should know whether we have 
any yield before we could ever have taped out the smaller design. If we get yield (or if 
we have functional Euterpe by then) then important work may proceed. 

If we have neither working Cronus nor Euterpe, then we're in much better shape to improve 
our Cronus yields by jumping on then- available (more appropriate) 3.3V .Sum technologies 
with a shrunk design that should then yield. 

Note that we still wouldn't need to go through the Herculean physical design task of a 
"tight" Cronus. I don't think that we can afford the resources that are required to go 
through such an effort on a design that has so many fundamental flaws (especially power 
and packaging) that will forever prevent Cronus from shipping in significant volume. 

That's my recollection on some of the rational behind this proposed decision. 
Perhaps Geert, Tim or Steve Manser would like to elaborate? 

Regards , 
Drew 

(my original message is included below ) 

> From: Drew Wingard on Wed, Jul 26, 1995 4:12 PM 

> Subject: Imminent Decision: Cronus die size 

> To: cronus 
> 

> The currently proposed Cronus die size is 20448 x 19008 urn (i.e. 3.89 cm A 2) . 

> This would give us 292 pads in the external pad ring (plus a 

> large -but -not -yet -completely- specif ied number of internal power pads) . 

> The horizontal edges would each contain 76 pads, while the vertical 

> edges would have 70. 
> 

> This size has been approved by both of our foundry partners. 
> 

> We plan to use this (larger -than- expected) size in order to simplify 

> the physical design and thus reduce the schedule risk. 
> 

> This decision is scheduled to become FINAL at 5pm on Friday, July 28. 
> 

> Regards, 

> Drew 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, July 26, 1995 10:06 PM 

To: manser 

Cc: abbott; bill; craig; geert; gmo; graham; hayes; lisar; mudge; tbr 

Subject: Input Please 


"manser" wrote (on Jul 26) : 

Euterpe is nearly completed. No known logic bugs, only another 40-50 
routes and timing paths need to be completed. Again, this should be 
do- able by FF. 

I think that it should be mentioned that as part of the Euterpe tapeout requirements we 
did successfully run all of the software acceptance tests that were required for tapeout 
and that we did boot and run the MicroKernel on the gate level design. Many thanks to all 
of the software groups in supporting that effort. 

2 When will we know if we have 100% success for those areas where we are 
close (Unix prompt, Euterpe routes, etc.)? Alternately, we can always get an 
update on Tuesday night to finalize. 

Regarding the Unix prompt. We have a little development work to do in order to get to a 
prompt - Enhancement of some behavioral models - and we've never run a job as long as 
this . 

My expectation is that we will have a prompt somewhere between the September and October 
first Fridays. (Of course we're aiming for sooner than later!) I've included an excerpt 
from today's software bringup meeting which illustrates the path. 

Lisa R. 


We had a short discussion about the progress of the shortened OSF test that is being run 
on the HW simulator. We believe that the run may have been interrupted by the shutdown of 
the file servers yesterday. We do believe that the test has progressed beyond the point 
at which it stopped last time due to a problem with snoopy and an errant reference to a 
cerberus register (hostio) . 

Once this test has run, the following steps have been accomplished. 

o kernel data structure have been initialized 
o the "probe 1 steps have been faked out. 
o all kernel memory is setup 

dynamic pages for text 

buffer caches 

The above steps are estimated to take about 30 milliseconds wall clock time. 

What remains to get us to a single user prompt? 

o mach__init 
o init 

o exec of a shell 

The total wall clock time estimate to do the entire boot and arrive at a single user 
prompt is about 150 milliseconds (not accounting for disk I/O) . 

Given these estimates we believe that the time required to run the OSF kernel on the HW 
simulator (using the IKOS and including support for snoopy/ s dram hostio support) will take 
about 150 hours. 
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Sent: 

To: 

Cc: 


Subject: 


From: 


manser [manser@charybdis] 

Wednesday, July 26, 1995 10:37 PM 

abbott; bili; craig; geert; gmo; graham; hayes; lisar; mudge; tbr 

manser@charybdis 

Input Please 


As you heard today at company lunch, we will be having a communications meeting next 
Wednesday. As part of this, I'd like to solicit input for examples of progress to be 
recognized (at the team level) . 

Here is a partial list of (near) accomplishments over the last few weeks: 
working oscillators (3 level metal) 
working Sisyphus CMOS and B I CMOS ring oscillators 

(near) clean Pollux design (this may be done by the end of this week) 

Mnemo is currently fully routed and timing accurate. However there are 
some logic fixes which need to be completed and rerouted/ timed. Again, 
this should be done prior to first Friday. 

Euterpe is nearly completed. No known logic bugs, only another 40-50 
routes and timing paths need to be completed. Again, this should be 
do- able by FF. 

OSF running on software simulator (not to prompt yet) . This validates the 
compiler and OSF port. 

- Others .. .Hestia, Pandora, etc. We will need to make sure we don't miss any 
major milestones across the company. 


Please provide me with your feedback by Friday on two subjects: 

1 Am I missing any areas (I apologize in advance)? 

2 When will we know if we have 100% success for those areas where we are close (Unix 
prompt, Euterpe routes, etc.)? Alternately, we can always get an update on Tuesday night 
to finalize. 


Steve 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Mark Semmelmeyer [mws@gaea.microunity.comI 
Wednesday, July 26, 1995 9:17 PM 
guarino@microunity.com; hayes@microunity.com 
compiler@microunily.com; craig@microunity.com; abbott@microunity.com; 
gmo@microunity.com; gregg@microunity.com; mws@microunity.com 
Re: another microarchitecture gotcha 


> From hayes@microunity.com Wed Jul 26 17:54:35 1995 

> Guarino wrote: 

> > At today's bring-up meeting, we were discussing the fact that branch 

> > prediction doesn't predict if the branch crosses a page boundary, 
[snip] 

> 

> Thanks. I asked Ethan about loop - dee - doop. . . 

I hope your reference to loop-dee-doop has to do 

with uncached if etches or icache fills; it has nothing 

to do with page crossing branches or sequential page crossers. 

> [snip] Of course, this means we'll either need an 

> asm-level nop (Mark has several in the opcode table, but none 

> are architecturally visible) 

You must have an old table or our using the TSA. Euterpe and cronus 
support the EN00P instruction at major opcode OxDD. You should not 
be seeing "several" . 

> There's 

> nothing the compiler can do about a loop bigger than the page size, 

> so the application developers need to beware. 

. ..although then the cost can be amortized over a larger chunk. 

> BTW, what's the branch penalty these days? 3 cycles? 
It is still 3 (not including counting 1 for executing the 
branch itself) . 
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From: Derek Iverson [doi] 

Sent: Wednesday, July 26, 1 995 7:53 PM 

To: pandora; hestia 

Subject: Software Bringup Meeting Minutes - July 26, 1995 


We had a short discussion about the progress of the shortened OSF test that is being run 
on the HW simulator. We believe that the run may have been interrupted by the shutdown of 
the file servers yesterday. We do believe that the test has progressed beyond the point 
at which it stopped last time due to a problem with snoopy and an errant reference to a 
Cerberus register (hostio) . 

Once this test has run, the following steps have been accomplished. 

o kernel data structure have been initialized 
o the "probe' steps have been faked out. 
o all kernel memory is setup 

dynamic pages for text 

buffer caches 

The above steps are estimated to take about 3 0 milliseconds wall clock time. 

What remains to get us to a single user prompt? 

o mach_init 
o init 

o exec of a shell 

The total wall clock time estimate to do the entire boot and arrive at a single user 
prompt is about 150 milliseconds (not accounting for disk I/O) , 

Given these estimates we believe that the time required to run the OSF kernel on the HW 
simulator (using the IKOS and including support for snoopy/ sdr am hostio support) will take 
about 150 hours. 


Next we talked about the SW/HW simulation accuracy project. Ethan has been able to modify 
terp so that all three of the items Jeffm identified as introducing time differences have 
been resolved. There is still a difference of about 7 0 minor cycles that still need to be 
identified. 


It may be crucial to have the capability to ensure that performance critical code sections 
do not cross page boundaries (and invalidate predicate branches) . 

Gmo is going to ensure that code in the micro kernel does not exhibit this behavior. 

Loretta is going to investigate the ability for C code to request/ensure proper alignment 
of code segments within a page. 


Wally reports that the remote debugging environment for euterpe basically works. He has 
been able to simulator break points, single stepping, displaying variables and registers, 
etc. Wally would like to do some addition work to allow attach/ detach capability, support 
a better method of interrupting the euterpe cylinders, and fix a problem related to 
printing variables that have been modified by a previous gdb command. 

Wally would like to be given a name of a test that he can use to test the loading and 
running capability. Jeffm suggested that we uses drameasy for this purpose. 
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Ethan reported that he has implemented almost all outstanding "above the bar' requests for 
SW simulator. 


We want to get performance results for if etch via the hemes channel. 
Tim will begin writing a test to measure this. 


Tim has released a new icache_j?erf test and Loretta has released a new performance test in 
the stb/stand/diag area called gtlb_perf . 


A list of architectural differences between euterpe and cronus is needed so that 
appropriate support in the SW simulator and diagnostics can be added. Jeffm has 
volunteered to pester tbr. 


We would like to make sure the the TCC compiled acceptance tests get run on the HW 
simulator. Lisar was not available for today's meeting and we are sure she could have 
filled us in on the progress of this item. 


That is all folks. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


graham (Graham Y. Mostyn) 
Wednesday, July 26, 1995 5:09 PM 
mudge 

tbr@gaea; geert; manser; rich 
Re: S2 resource meeting 


I consider Sisyphus, Pollux and Castor all playing vital but different roles in helping to 
bring up the fab. When we've all agreed on the relative tapeout priorities, my interest 
would be in adding design resource to this third chip, as well, to help speed completion. 
In the meantime, Rich McCauley and I would be interested in joining you on the Castor 
sessions. 

Regards , Graham . 

> From mudge Wed Jul 26 14:43:50 1995 

> Date: Wed, 26 Jul 1995 14:43:46 -0700 

> From: mudge (john mudge) 

> To: graham 

> Subject: Re: S2 resource meeting 

> Cc: tbr@gaea, geert, manser, mudge 

> Content -Length: 1299 
> 

> Graham, 

> Chris, Tom Ho, Paul and myself have set up regular working meetings to 

> design, layout and track castor 2 . These got interrupted by sisyphus 

> 1 and now will be interrupted by sisyphus 2. Castor 2 is basically an 

> update to the new rules of castor 1 and there are some analog related 

> structures on castor 1 so input from the analog design team could be 

> helpful. What did you have in mind? If you want to join the meetings or send a 
representative, let me know. 

> 

> j ohnnymudge 


> 
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Subject: 


Sent: 

To: 

Cc: 


From: 


graham (Graham Y. Mostyn) 
Tuesday, July 25, 1995 6:21 PM 

geert@gaea; graham@gaea; mudge@gaea; manser@charybdis 
tbr@gaea 

Re: S2 resource meeting 


In this same vein of assisting the fab, I'd like to receive more visibility on Castor, and 
how the design team can help there too. 

Castor, which is more structure and less circuit-oriented than Pollux/Sisyphus, seems 
indispensable to me for the fab to pursue device diagnosis and design rule changes. 

I would propose a separate but related meeting to ensure there are no open issues (such as 
resource and tapeout 
schedule) for this chip too. 


Graham , 
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From: 
Sent: 
To: 
Cc: 

Subject: 


Tom Elch [tbe@microunity.com] 
Monday, July 24, 1995 7:22 PM 
jack; geert; hchu; bill; tbr; pmayer; trancy 
cronus; pandora; wingard 

Results of Cronus mounting and pcb design meeting 


The following are actions and results from the meeting held 7/24 relative to Cronus 
mounting, de- coupling, and pcb design. 

1) No metal on the back of the die or the Micro Module space transformer. 

2) Thickness of die: It is strongly desired to have one die thickness and tolerance, 
regardless of sourcing, else we have to have n different parts given n different 
thicknesses. This would also apply to the spacer and the assembly. 

a) Jack to determine standards and options for TSMC and CSM. Done: 

Jack wrote: 

>Herman, 
> 

>Both TSMC and CSM back- grind to 19 mils or 480 microns final wafer 

> thickness . 

> 

>TSMC's tolerance is ■+•/- 1 mil; CSM is checking. 
> 

>Both vendors are investigating whether or not they can back- grind to 

>Euterpe's 25 mil thickness. 

> 

>- Jack 

b) Jack to determine standard flatness and finish for both vendors or get technical 
contact for same in touch with Herman. 

c) Trancy to provide dimension and tolerance for bump/seal ring for Cronus with MMS s/t. 

3) Pattie to get snapshot of Cronus pad assignments and place rats nest with maximum 0805 
caps on bottom side for Bill et al to review. 

4) Tbr to ensure that pcb design criteria is considered in final Cronus pad assignments. 
Please follow up with any corrections or closure here. 

Regards , 
-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 940 89 
(408)734-8100, (408)734-8177 fax 


tbe@microunity . com 


Any opinions expressed 
above are mine 
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From: manser [manser@charybdis] 

Sent: Monday, July 24, 1995 4:10 PM 

To: bill; craig; geert; gmo; graham; gregg; hayes; lisar; mudge; tbr; wingard 

Cc: abbott; jack; manser@charybdis; mouss@charybdis 

Subject: 1st Zeus Meeting 


Here are the notes and actions from the first CMOS (code name: Zeus) microprocessor 
discussion. Preliminary feature set: 

TSMC 0.5 

size = 1/2 reticle 
Speed/ Power 

Cable Modem @ 10W 

Hestia @ 40W 

Schedule 

Tapeout Q4 96 

Sample 1H 97 

Production 2H97 

Review of features raised the following (types of) questions: 

How much support for X8S should be in hardware /software and how important is 
the performance level vs Intel? 

Need to better understand performance variations between multiple threads 

and 

multiple issue. 

Need more data on industry profile on technology - is 0.5 TSMC aggressive 
enough? Need inventory of foundries for technology vs time. 

Need to better understand metal systems and implication on Zeus design. 

What packaging assumptions should be assumed for low cost /power? 

- Need to understand transistor size for random logic and memory vs Zeus. 

If the goal is to make this a PORTABLE core, we should insure that the 
processor is very modular and can have other logic easily added. 

More data is needed to converge on a small subset of discussions. It was agreed that, to 
move quickly, there would be three separate teams which will investigate major topic areas 
in parallel and return their findings (and 

proposals) back to the larger forum. These teams are as follows. 


Technology Group - 

Goal: Survey the landscape, gather info, make assumptions, and make proposals 

on technology issues related to Zeus. 
Team leader: Bill 

Team members: Bill, Johnny, Geert, Drew, Craig 

Preliminary issues: packaging, metals, transistors, die size, industry 
direction and vendor base. 


Architecture Group - 

Goal: Synthesize existing performance data with new X86 goals and make 

proposal on alternative architectural implementations. 
Team leader: Craig 

Team members: Drew, Geert, Tim, Lisa, Gregg, Gmo, Ray 

Preliminary issues: current performance and instruction traces, cycle 

efficiency, X86 instruction support, compiler modifications. 
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Marketing Group - 

Goal: Working with Marketing (ie Tony) strive to better define Zeus 
feature, 

cost, schedule tradeoffs. 
Team leader: Graham 

Team members: Craig, Steve, Tim, <Tony) 
Preliminary issues: features, cost target, etc. 


Team leaders should have the responsibility of calling meetings, summarizing 
meeting minutes and actions and summarizing discussions to the larger forum. 
Also, While new architecture's are always more interesting, Steve asks that 
we make sure that we keep a balanced approach to insure that the 
investigatory work does not impact Euterpe, Cronus, and TCI RFP related 
activities . 

Next meeting is scheduled for Friday the 2 8th from 1-2 in the War Room. I 
would ask that team leaders have a 1 page summary of progress. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Hieu Tran,Acct Mgr.CSMSJ [tran@csminc.com] 

Monday, July 24, 1995 1:22 PM 

jack 

dobrushi; geert; tbr; warn pier; wingard; wong 
RE: Prototype chip die size 


Hello Jack, 


This die size is fine for ASM reticle field. Please update the tape out schedule if you 
have a chance. 
Regards , 
Hieu 


From: jack 
To: tran 

Cc: dobrushi; wong; wingard; geert; tbr; wampler; jack 
Subject: Prototype chip die size 
Date: Monday, July 24, 1995 10:41AM 


The currently proposed die size for our prototype run 
is 20448 x 19008 urn (i.e. 3.89 cm*2) . 

Please confirm that this will be acceptable. 

Regards , 
Jack 


Jack Wenstrand Tel: (408) 734-8100 

MicroUnity Systems Engineering, Inc. Fax: (4 08) 734-8141 
255 Caspian Drive 

Sunnyvale, CA 94089-1015 email: jack@microunity.com 


Hieu, 


Exhibit C16 


Page 53 of 12 


From: graham (Graham Y. Mostyn) 

Sent: Monday, July 24, 1 995 1 1 :29 AM 

To: geert@charybdis; graham@gaea; hopper@gaea; lisar@gaea; tbr@gaea; manser@charybdis 

Subject: RE: more on "Progress towards Products" 

3 - 3.30 will be fine for me. I agree that it T s really important for us to recognize our 
accomplishments . 

Graham . 

> From manser@charybdis Sat Jul 22 12:57:41 1995 

> Date: 22 Jul 1995 12:56:21 -0800 

> From: "manser" <manser@charybdis> 

> Subject: RE: more on "Progress towards Products" 

> To: "Geert Rosseel" <geert@charybdis>, "graham" <graham@gaea> , 

> "hopper" <hopper@gaea> , "lisar" <lisar@gaea> , "tbr" <tbr@gaea> 

> Content-Length: 1952 
> 

> Just noticed I have a 10-11 Cronus meeting... so how about 3-3:30 instead? 


From: Geert Rosseel on Sat, Jul 22, 1995 12:02 PM 
Subject: more on "Progress towards Products" 
To: graham; hopper; lisar; manser; tbr 
Cc : mouss 


> Hi, 
> 

> 

> A couple of things happened this week that made me think about the 

> sending this mail . 
> 

> 1 . We celebrated lots of working ringoscillators 

> 2 . Tom Vo finished a 926 ps Mnemosyne (Mnemo 

> still needs some verification, but what 

> Tom and Alan and other people have done is 

> a big achievement) 

> 3 . Tim got very close a 1GHz Euterpe . 
> 

> I realized that actually what we have today, barring DRC changes, is 
> 

> -> "close to a 1 GHz " Euterpe 

> -> a 926 ps Mnemosyne (well, it misses timing with ,36ps) -> a 

> Pollux 

> 

> If we didn't have design rules changes, we could tape all these out 

> in a very short amount of time. I was wondering if somehow we could 

> decouple recognizing the fact that we finished these designs from the 

> actual "tape-out" which is very fab-dependent (and might take a while 

> from now) . 
> 

> I think, under the current circumstances, from the design 

> perspective, we can consider a design done when we have an LVS clean, 

> logically verified database. 
> 

> It seems very fair to me to make the statement that we've finished 

> these designs and we only have the rev the layouts to the new DRC 

> rules and tape them out. ("only" is a bit of an understatement, but 

> still true compared to the massive amount of work that already has 
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gone in these designs) 

So, it seems to me it might be good to give some company wide 
visibility to the fact that we have "finished" the above designs, once 
we all agree that we have LVS clean fully verified databases. When 
all three designs are "done", we could have some announcement at a 
First Friday Meeting or Wednesday lunch or something . . . 

Geert 
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Sent: 

To: 

Cc: 


Subject: 


From: 


solo {John Campbell) 
Monday, July 24, 1995 9:45 AM 
lisar (Lisa Robinson) 

vanthof (Dave Van't Hof); tau; hopper (Mark Hofmann); geert (Geert Rosseel); tbr (Tim B. 
Robinson); age (Alan Corny) 
we got one (Iwd) 


as Tim B. Robinson was saying 

It's also csyn clean . 

Pending results of other verification , we're ready for the 
tapeout process . 

. .Well done all! 


sounds like we should turn on the mnemo verification of drc Ivs for its custom blocks, 
starts again tonight. 


Tim 


regards , 

solo a.k.a. John Campbell 


X516 
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From: 
Sent: 
To: 

Subject: 


lisar (Lisa Robinson) 

Saturday, July 22, 1995 11:38 PM 

for 

Mnemo PCI status 


Begin Included Message 

>From deepak Sat Jul 22 18:49:13 1995 
Return- Path: <deepak> 

Received: from ast.microunity.com by gaea.microunity.com (4 . l/musel . 3) 

id AA22556; Sat, 22 Jul 95 18:49:06 PDT 
Received: from localhost by ast.microunity.com (8 . 6 . 4/muse-sw. 3 ) 

id SAA25923; Sat, 22 Jul 1995 18:49:05 -0700 
Date: Sat, 22 Jul 1995 18:49:05 -0700 
From: deepak (Deepak Tripathi) 

Message-Id: <199507230149 . SAA25923@ast .microunity . COm> 

To; deepak, lisar 

Subject: Mnemo PCI status 

Cont ent - Length : 1 2 2 0 0 

X-Lines: 184 

Status : RO 


The checked in mnemo database (which is now tapeout ready) still has 
a few bugs. They can be classified as follows: 

NOTE: For all these tests, the LMC modules respond in 32bit mode 


1> PCI Retry mechanism: 

These bugs are essentially related to the "retry mechanism" 
as tested by the tests ms7 & ms9. I had put in a fix for this earlier 
but it turned out to be incomplete because for some corner cases with 
64bit v/s 32bit datasizes. 

There turned out to be another bug related with the handshaking between 
the pci modules and the rest of mnemo. The data read in on a re-tried 
"PCI Read" cycle wasn't pushed back to the sram buffer. 
Both of these are now fixed. 

2> DMA controller bug: 

All the above retry bugs also fall in this catergory (i.e, the retry 
mechanism broke down when mnemo was executing a dma command) . 
The other bugs are related to 64bit v/s 32bit datasizes. The pci 
cycle terminated incorrectly if the dma stream had to terminate 
after transferring only half an octlet from the last octlet (only the 
lower 32bits of the last octlet word) . This one is fixed. 

But there is as yet an unfixed one, if only one octlet has to be transferred 
using a dma write command, then mnemo splits the transaction into 
two 32bit pci cycles (whereas for reads, it fetches both 32bit words 
in a single transaction) . Analysis pending on this. 

3> Hermes Packet arrival time related bugs. 

Again this has to do with mnemo in the dma mode. If the Hermes command 
packets come in too close to each other, the dmacontroller can get 
really confused, (look at comments for ms7 & ms9) . I was able to get 
ms7 to pass by inserting more idle packets into the stream) . 
I haven't seen a similar failure with the PI0 mechanism, since PI0 
transactions are a lot shorter than DMA and therefore the window (if 
one exists) of failure might be a lot shorter, (also it's a lot more 


Lisa, 


only 
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fun breaking the dma controller :-) 


In the table below the following caveat applies: 

The entire Target suite and tests msl3, msl5 & msl6 (of the master suite) 
haven't been run with all the new fixes yet. These were passing earlier 
and I haven't touched any of the arbiter or target modules but I still have 
to make sure I haven't broken anything. 

From the testing point of view, there's eseentially a lot still left to do. 
The entire suite below has to be run in the pure 64bit mode. If that runs 
fine, then by induction, Clio should have very few problems (as all the 
64bit v/s 32bit logic is being clipped out of Clio pci ) . 


PCI Compliance Suite 


Test | Status \ Comments j 


Master scenario 1 
Master Abort cycles 

Pass 

Need to stop mncheck from 1 
tripping over legit, error | 
response packets. 

Master scenario 2 
Target Abort cycles 

Pass 

Squeeze out idle time in i 
betw. transactions. j 

Master scenario 3 
Target Retry cycles 

Pass 

Everything looks fine. ] 

Master scenario 4 
Single Data disconnect 

Pass 

Everything OK. j 

Master scenario 5 

Not app 1 i cable 

Deleted from suite . | 

Master scenario 6 
Multi-Data phase 
Target abort cycles 

pass 

Test passes, 
(only for memory and 
config cycles) 
Have to include mera_rd_mul 
mem_rd_line & mem__wr_inv. 

Master scenario 7 
Multi-Data phase 
Retry cycles 

pass (almost) 

Discovered corner case 
related to Hermes pkt . 
arrival time. Analysis 
incomplete but test passes 
when more idle packets are 
added inbetween command 
packets 

Master scenario 8 

Not applicable 

Deleted from suite. j 

Master scenario 9 
Multi-Data Phase 
Disconnect Cycles 

pass (almost) 

Same comment as for ms7 

Master scenario 10 
Multi-Data Phase & 
TRDY# Cycles 

pass 

All O.K. 

Master scenario 11 

pass 

All O.K. | 
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Data Parity Error 
Single Cycles 


Master scenario 12 
Data Parity Error 
Multi-Data Phase Cycles 

pass 

All O.K. 

Master scenario 13 
Bus Master Timeout 

pass 

Timeout inefficient. 
Non-pci modules cannot 
back up fast enough. 

Master scenario 14 
Target Lock 

Not applicable 

Not applicable . Mnemo does 
not support LOCK accesses . 

Master scenario 15 
Bus Master Parking 

Pass 

Bus Parking test. Also 
covered by other tests. 

Master scenario 16 
Bus Master Arbitration 

Pass 

Mnemo can generate a 
generate a transaction w/ 
GNT active for 1 elk only. 


Target scenario 1 Not applicable 
interrupt cycle 

Not applicable. Mnemo will 
respond to intr.ack cycles 

Target scenario 2 Pass. j Mnemo does not respond to 
special cycle | j Special cycles. 

Target scenario 3 
address and data parity 
error for special cycle 

Pass. 

SERR asserted as expected. 
Config bits controlling 
SERR checked out. 

Target scenario 4 

I/O cycles with legal & 

illegal byte enables 

Pass 

Mnemo does not have to 
check for illegal AD/BE 
combinations on IO cycles. 

Target scenario 5 
reserved commands 

Pass 

Mnemo does not respond 
to resv, commands. 

Target scenario 6 
configuration cycles 

Pass 

Mnemo does not respond 

to config cycles with j 

AD[1:0] 1= '00 j 

Target scenario 7 

I/O cycles with address 

& data parity errors 

Pass 

SERR and PERR asserted but | 
no corr. Hermes error 
packets. OK for mnemo as 
target . 

Target scenario 8 
config. cycles w/ addr 
Sc data parity errors 

pass 

Mnemo asserts PERR and 
SERR correctly on data & 
addr. parity errors resp. 

Target scenario 9 
memory cycles 

pass 

Mnemo signals a disconnect 
for accesses that cross- 
over defined boundary. 

Target scenario 10 
memory cycles w/ addr. 
& data parity errors 

Pass 

Passes the compliance 
requirements. Adding addl. 
cycles to verify config. 
space status register. 

Target scenario 11 
fast back to back 

Not applicable 

Not applicable. Mnemo does) 
not support fast back- to- j 
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cycles 


i 


back cycles. 


i 


Target scenario 12 

Not applicable 

Not applicable. Mnemo does 

Target scenario 13 
cycles with irdy used 
for data stepping 

pass 

passes the compliance 
requirements . 


I 


End Included Message 
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From: 
Sent 
To: 

Subject: 


tbr 

Saturday, July 22, 1995 4:27 PM 

hopper (Mark Hofmann) 

RE: more on "Progress towards Products" 


Mark Hofmann wrote (on Sat Jul 22) : 

Tim B , Robinson writes: 

"manser" wrote (on Jul 22) ; 

Just noticed I have a 10-11 Cronus meeting... so how about 3-3:30 instead? 

Sounds good to me. BTW, one more euterpe route iteration just 
completed and it's down to 54 paths failing. I'll get another turn in 
before the meeting . . . 


I'm in agreement with Geert ' s perspective on this. 
The 3-3:30 slot is fine for me. 

Tim- that's even better news on Euterpe. Whatever you're doing, it sounds 
like you've perfected the recipe! 

well, there is one point of imperfection. At each iteration I typically have to manually 
adjust placemetn of about 3 or 4 cells. 

Is there was some way of having them automatically adjusted to fit, then it would be 
possible to just let it iterate ad nauseam same as we do for the subblocks till we get a 
good solution. However, since I am makint the strenght, pirn and net cap files source 
files, it's not too bad because all the history is preserved if you check out a clean copy 
and build it. It's like you start off witht hebenefit of 5 iterations, so I'd say it's 
not worthe any big new effort at this point. 

I think a day or so for kurt and torn vo's time ought to be able to polish this one off to 
no violations. My next turn should be out tomorrow, and on the present trajectory I'm 
expecting -20 errors. 


Tim 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Saturday, July 22, 1995 9:10 AM 
Tim B. Robinson 

manser@charybdis; geert@charybdis; graham@gaea; hopper@gaea; lisar@gaea 
RE: more on "Progress towards Products" 


Tim B. Robinson writes: 

"manser" wrote (on Jul 22) : 

Just noticed I have a 10-11 Cronus meeting. .. so how about 3-3:30 instead? 

Sounds good to me. BTW, one more euterpe route iteration just 
completed and it's down to 54 paths failing. I'll get another turn in 
before the meeting . . . 


I'm in agreement with Geert's perspective on this. 
The 3-3:30 slot is fine for me. 

Tim- that's even better news on Euterpe. Whatever you r re doing, it sounds like you've 
perfected the recipe! 


Tim 


-hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


manser [manser@charybdis] 
Saturday, July 22, 1995 4:21 PM 
Tim B. Robinson; Tom Vo 

Alan Corny; Dave Van't Hof; Geert Rosseel; Kurt Warn pier; Lisa Robinson; 
manser@charybdis; Mark Hofmann; mnemo@charybdis; mouss@charybdis; Richard 
Dickson; tau@charybdis 
RE: we got one 


Hey guys - this is great news! With the progress over the last few days/weeks, you should 
all feel proud of what you are accomplishing. While we are not yet finished, you are 
making excellent progress! Keep it up!! 


From: Tim B. Robinson on Pri, Jul 21, 1995 10:10 PM 
Subject: we got one 
To: Tom Vo 

Cc: Alan Corry; mnemo; manser; mouss; Richard Dickson; Geert Rosseel; Mark Hofmann; Lisa 
Robinson; tau; Dave Van't Hof; Kurt Wampler 


Tom Vo wrote (on Fri Jul 21) : 


The latest and greatest mnemo is now fully routed and 
timed at 926.38ps according to topt . 

Rat's you beat me! Hey this is fantastic - I'll allow you that 0.38 of a picosecond! 

It's also csyn clean . 

Pending results of other verification , we're ready for the 
tapeout process . 

Well done all! 


Steve 


Tim 
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From: geert (Geert Rosseel) 

Sent: Saturday, July 22, 1 995 2:02 PM 

To: graham; hopper; lisar; manser; tbr 

Cc: mouss 

Subject: more on "Progress towards Products" 


Hi, 

A couple of things happened this week that made me think about the sending this mail. 

1. We celebrated lots of working ringoscillators 

2. Tom Vo finished a 926 ps Mnemosyne (Mnemo 
still needs some verification, but what 
Tom and Alan and other people have done is 
a big achievement) 

3 . Tim got very close a 1GHz Euterpe . 

I realized that actually what we have today, barring DRC changes, is 
-> "close to a 1 GHz" Euterpe 

-> a 926 ps Mnemosyne (well, it misses timing with .36ps) -> a Pollux 

If we didn't have design rules changes, we could tape all these out in a very short 
amount of time. I was wondering if somehow we could decouple recognizing the fact that we 
finished these designs from the actual "tape-out" which is very fab-dependent (and might 
take a while from now) . 

J think, under the current circumstances, from the design perspective, we can consider a 
design done when we have an LVS clean, logically verified database. 

It seems very fair to me to make the statement that we've finished these designs and we 
only have the rev the layouts to the new DRC rules and tape them out. ("only" is a bit of 
an understatement, but still true compared to the massive amount of work that already has 
gone in these designs) 

So, it seems to me it might be good to give some company wide visibility to the fact that 
we have "finished" the above designs, once we all agree that we have LVS clean fully 
verified databases. When all three designs are "done", we could have some announcement at 
a First Friday Meeting or Wednesday lunch or something . . . 


Geert 
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Subject 


Sent: 
To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, July 22, 1995 12:10 AM 

vo (Tom Vo) 

age (Alan Corry); mnemo; manser; mouss; dickson (Richard Dickson); geert (Geert Rosseel); 
hopper (Mark Hofmann); lisar (Lisa Robinson); tau; vanthof (Dave Van't Hof); warn pier (Kurt 
Wampler) 
we got one 


Tom Vo wrote (on Fri Jul 21) : 

The latest and greatest mnemo is now fully routed and. 
timed at 92 6.38ps according to topt . 

Rat's you beat me! Hey this is fantastic - I'll allow you that 0.38 of a picosecond! 

It's also csyn clean , 

Pending results of other verification , we're ready for the 
tapeout process . 

Well done all! 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr 

Saturday, July 22, 1995 12:10 AM 
vo (Tom Vo) 

age (Alan Corry); mnemo; manser; mouss; dickson (Richard Dickson); geert (Geert Rosseei); 
hopper (Mark Hofmann); lisar (Lisa Robinson); tau; vanthof (Dave Van't Hot); wampier (Kurt 
Wampler) 
we got one 


Tom Vo wrote (on Fri Jul 21) : 

The latest and greatest mnemo is now fully routed and 
timed at 926.38ps according to topt . 

Rat's you beat me! Hey this is fantastic - I'll allow you that 0.3 8 of a picosecond! 

It's also csyn clean . 

Pending results of other verification , we're ready for the 
tapeout process . 

Well done all ! 

Tim 
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From: vo (Tom Vo) 

Sent: Friday, July 21, 1995 7:18 PM 

To: lisar (Lisa Robinson); tbr (Tim B. Robinson); age (Alan Cony); dickson (Richard Dickson); 

geert (Geert Rosseel); hopper (Mark Hofmann); tau; wampler (Kurt Wampler); vanthof (Dave 
Van't Hot) 

Subject: we got one 


The latest and greatest mnemo is now fully routed and timed at 926.38ps according to topt 
It's also csyn clean . 

Pending results of other verification , we're ready for the tapeout process . 
tvo 
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Subject: 


Sent: 

To: 

Cc: 


From: 


trancy [trancy@charybdis] 
Thursday, July 20, 1995 9:44 PM 
Tom Eich 

bill; geert; Herman Chu; pmayer; Tim B. Robinson; wingard 
RE: Cronus pcb layout and mechanical mounting 


Hi Tom, 


Let's meet next Monday because I have to attend a Workshop tomorrow. 

Regards . 
Trancy . 


From: Tom Eich on Thu, Jul 20, 1995 6:12 PM 
Subject: Cronus pcb layout and mechanical mounting 
To: trancy; pmayer; bill; tbr; hchu 
Cc : geert ; wingard 

I am anticipating a problem with the cronus pcb assembly design. 

Specifically, the decision to go to a 7 0mm TAB frame calls into question the use of the 
existing heat sink clamp and spacer (developed for Calliope and Euterpe on Hestia) . This 
is because of the constraints placed on pcb layout around Cronus on both the top and 
bottom side of the pcb. 

The problem is one of extremely limited bottom side pcb area due to the combination of the 
keepout for the TAB tooling and the keepout for the current clamp , and limited top side 
pcb area due to the combination of the heat sink spacer and the 70mm TAB pattern. I need 
your help to sort out the options and would therefore like to meet to review the problem. 
Can we do this on Friday, at 4:00pm in the boxers conference room? 


Thanks , 


-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94089 
(408)734-8100, {408)734-8177 fax 


tbeOmicrounity . com 


Any opinions expressed 
above are mine 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Tom Elch [tbe@microunity.com] 
Thursday, July 20, 1995 8:11 PM 
trancy; pmayer; bill; tbr; hchu 
geert; wingard 

Cronus pcb layout and mechanical mounting 


I am anticipating a problem with the cronus pcb assembly design . 

Specifically, the decision to go to a 70mm TAB frame calls into question the use of the 
existing heats ink clamp and spacer (developed for Calliope and Euterpe on Hestia) . This 
is because of the constraints placed on pcb layout around Cronus on both the top and 
bottom side of the pcb. 

The problem is one of extremely limited bottom side pcb area due to the combination of the 
keepout for the TAB tooling and the keepout for the current clamp, and limited top side 
pcb area due to the combination of the heat sink spacer and the 7 0mm TAB pattern. I need 
your help to sort out the options and would therefore like to meet to review the problem. 
Can we do this on Friday, at 4:00pm in the boxers conference room? 


Thanks , 


-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94 089 
(408)734-8100, (408)734-8177 fax 


tbe@microunity . com 


Any opinions expressed 
above are mine 


Exhibit C16 


Page 69 of 12 


From: vanthof (vant) 

Sent: Thursday, July 20, 1995 1 :04 AM 

To: Tim B. Robinson 

Cc: wingard (Drew Wingard); bobm (Bob Morgan); craig (Craig Hansen); cronus; dickson (Richard 

Dickson); vanthof (Dave Van't Hof) 
Subject: Re: cronus cerberus regiters 0-5 


Tim B. Robinson writes: 
> 

>Then we had better ammend the schedule to reflect this fact. As far as 
>I was aware we had adopted a subset of the design rules to be 
>compatible with both and I don't think the schedule has ever shown two. 
>With the current methodology, it 1 s much more than the drc that would 
>get duplicated since we would have to have two different routes, two 
>different LVS runs and two different logic regression passes. 
> 

>It remains the case that anything we are required to do which will slow 

>down either tapeout is a bad thing. 

> 

>For future designes we clearly need a different approach to the way 
>these registers get personalized so as to avoid a hit like this. 
> 

>Tim 


Tim is correct. If we really want different registers in the various foundry specific 
chips, then we will need a source for each foundry. The current methodology for 
drc/lvs/ tapeout is to have only _one_ source and the variations would be implemented at 
layout verification and fracture times in the drc and tapeout flows. This allows us to 
parallelize the tapeouts to each foundry. 

Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb.,, just 
not in this context." The Tick to Thrackazog 
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From: tbr (Tim B. Robinson) 

Sent: Thursday, July 20, 1995 12:53 AM 

To: wingard (Drew Wingard) 

Cc: bobm; craig; cronus; dickson 

Subject: Re: cronus cerberus regiters 0-5 


Drew Wingard wrote (on Wed Jul 19) : 
Tbr wrote: 

> Craig Hansen wrote (on Wed Jul 19) : 

> 

<snip> 

> 

> With the above information, I would use just a new manufacturer 

> code, which shall be (drum roll please) 0x00 40 a3 b4 ed fe. 

> 

> So octlet 2 changes from 0x00 40 a3 69 db 3f 01 00 

> to 0x00 40 a3 b4 ed fe 01 00. 

> 

> The manufacturer code should be distinct for each Cronos vendor, 

> to facilitate tracking, so if we are taping out to >1 vendor, 

> I'll assign some additional codes. 
> 

> That presents us with an additional challenge. My understanding is 

> the current plan is to tape out identical masks to the two vendors 

> (geert can you comment on this please) . Although it would logically be 

> a trivial change to have this number different between the two and a 

> valuable feature to help track things after fab and packaging, having 

> to handle two independent tapouts may add an unacceptable delay to one 

> of them, at least for the first version. We are assigning two 

> different part numbers because there are physical differences (such as 

> wafer thickness) which affect the packaging. 
> 

> Tim 


We can't tape out *identical* masks to our two foundries for a couple of 
reasons : 

1. Different design rules 

2. Different layer names 

3. Different layer biases/fields 

We'll need to at least have separate fracturing flows. I would claim that we 
really have two tapeouts. Since we know which vendor has better turnaround 
time (and better yield), I think that we know which one to tapeout first. 

Then we had better ammend the schedule to reflect this fact. As far as I was aware we had 
adopted a subset of the design rules to be compatible with both and I don't think the 
schedule has ever shown two. With the current methodology, it's much more than the drc 
that would get duplicated since we would have to have two different routes, two different 
LVS runs and two different logic regression passes. 

It remains the case that anything we are required to do which will slow down either 
tapeout is a bad thing. 

For future designes we clearly need a different approach to the way these registers get 
personalized so as to avoid a hit like this. 


Tim 
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From: tbr 

Sent: Thursday, July 20, 1 995 1 2:53 AM 

To: wingard (Drew Wingard) 

Cc: bobm; craig; cronus; dickson 

Subject: Re: cronus cerberus regiters 0-5 


Drew Wingard wrote (on Wed Jul 19) : 
Tbr wrote : 

> Craig Hansen wrote (on Wed Jul 19) : 
> 

<snip> 

> 

> With the above information, I would use just a new manufacturer 

> code, which shall be (drum roll please) 0x00 40 a3 b4 ed fe. 

> 

> So octlet 2 changes from 0x00 40 a3 69 db 3f 01 00 

> to 0x00 40 a3 b4 ed fe 01 00. 

> 

> The manufacturer code should be distinct for each Cronos vendor, 

> to facilitate tracking, so if we are taping out to >1 vendor, 

> I'll assign some additional codes. 
> 

> That presents us with an additional challenge. My understanding is 

> the current plan is to tape out identical masks to the two vendors 

> (geert can you comment on this please) . Although it would logically be 

> a trivial change to have this number different between the two and a 

> valuable feature to help track things after fab and packaging, having 

> to handle two independent tapouts may add an unacceptable delay to one 

> of them, at least for the first version. We are assigning two 

> different part numbers because there are physical differences (such as 

> wafer thickness) which affect the packaging. 


We can't tape out *identical* masks to our two foundries for a couple of 
reasons : 

1. Different design rules 

2. Different layer names 

3. Different layer biases/fields 

We'll need to at least have separate fracturing flows. I would claim that we 
really have two tapeouts. Since we know which vendor has better turnaround 
time (and better yield), I think that we know which one to tapeout first. 

Then we had better ammend the schedule to reflect this fact. As far as I was aware we had 
adopted a subset of the design rules to be compatible with both and I don't think the 
schedule has ever shown two. With the current methodology, it's much more than the drc 
that would get duplicated since we would have to have two different routes, two different 
LVS runs and two different logic regression passes. 

It remains the case that anything we are required to do which will slow down either 
tapeout is a bad thing. 

For future designes we clearly need a different approach to the way these registers get 
personalized so as to avoid a hit like this. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 
Wednesday, July 19, 1995 11:13 PM 
lisar; wingard 

bobm; craig; cronus; dickson; tbr; vanthof 
Re: cronus cerberus reglters 0-5 


Drew writes: 


> We can't tape out *identical* masks to our two foundries for a couple 

> of 

> reasons : 

> 1. Different design rules 

> 2. Different layer names 

> 3. Different layer biases/fields 
> 

> We ' 11 need to at least have separate fracturing flows . I would claim 

> that we really have two tapeouts . Since we know which vendor has 

> better turnaround time (and better yield) , I think that we know which one to tapeout 
first . 

Lisa R. replies: 


©Uhmm, I agree with Tbr that given the way we tapeout today, a seperate ©tapeout (ie some 
logical difference) would represent a delay for one. 

©maintaining a snapshot database is not a trivial task, double the @LVS/DRC/Functional 
verification is not represented in the schedule (In ©fact thinking about it the best way 
to accomplish this would be to ©serialize the process and avoid taking a branch!). 
© 

©My understanding was that the DRC flow was a superset of the 2 flows ©and thus final DRC 
would we done once and that differences associated ©with the 2 vendors would be entirely 
at the back end. 

In our layout methodology, as I understand it, we generate one set of 
layout files that are not strictly legal for either foundry. At tapeout 
time, a certain amount of synthesis is performed to render the layout 
compliant with the target foundry's layout rules. These synthesis steps 
are part of the DRC flow, but are different for the two target foundries, 
so the DRC flows are different. (Dave Van't Hof can correct me if I'm 
mis-stating the methodology here.) 

As part of the DRC/ Synthesis flow, we will also perform foundry- specif ic 
biases, tone inversions, and then create pattern files for each of the 
foundries . 

I believe we intend to assign separate "device numbers" to the two 
versions of Cronus from the two foundries, so that wafers, dice, etc. 
are still traceable to which foundry they came from. These device 
numbers, right now, are separate from, and unrelated to the part numbers 
used for board-level parts lists. (Ultimately these would be linked 
together in some sort of database . ) 

It might be be advantageous to have the I.D. register be different 
between the two different foundry versions of Cronus, but it's probably 
not necessary if we mark the packaged parts with an external code 
that allows us to distinguish which foundry they came from. 


- Kurt 
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From: fisar (Lisa Robinson) 

Sent: Wednesday, July 19, 1995 10:54 PM 

To: wingard (Drew Wingard) 

Cc: bobm; craig; cronus; dickson; tbr 

Subject: Re: cronus cerberus regiters 0-5 


Drew Wingard wrote (on Wed Jul 19) : 
Tbr wrote: 

> Craig Hansen wrote (on Wed Jul 19) : 
> 

<snip> 

> 

> With the above information, I would use just a new manufacturer 

> code, which shall be (drum roll please) 0x00 4 0 a3 b4 ed fe. 
> 

> So octlet 2 changes from 0x00 4 0 a3 69 db 3f 01 00 

> to 0x00 40 a3 b4 ed fe 01 00. 
> 

> The manufacturer code should be distinct for each Cronos vendor, 

> to facilitate tracking, so if we are taping out to >1 vendor, 

> 1 1 11 assign some additional codes . 
> 

> That presents us with an additional challenge. My understanding is 

> the current plan is to tape out identical masks to the two vendors 

> (geert can you comment on this please) . Although it would logically be 

> a trivial change to have this number different between the two and a 

> valuable feature to help track things after fab and packaging, having 

> to handle two independent tapouts may add an unacceptable delay to one 

> of them, at least for the first version. We are assigning two 

> different part numbers because there are physical differences (such as 

> wafer thickness) which affect the packaging. 
> 

> Tim 

We can't tape out *identical* masks to our two foundries for a couple of 
reasons : 

1. Different design rules 

2. Different layer names 

3 . Different layer biases/fields 

We'll need to at least have separate fracturing flows. I would claim that we 
really have two tapeouts. Since we know which vendor has better turnaround 
time (and better yield), I think that we know which one to tapeout first. 

Regards , 
Drew 

Uhmm, I agree with Tbr that given the way we tapeout today, a seperate tapeout (ie some 
logical difference) would represent a delay for one. 

maintaining a snapshot database is not a trivial task, double the LVS/DRC/Functional 
verification is not represented in the schedule (In fact thinking about it the best way to 
accomplish this would be to serialize the process and avoid taking a branchl) . 

My understanding was that the DRC flow was a superset of the 2 flows and thus final DRC 
would we done once and that differences associated with the 2 vendors would be entirely at 
the back end. 

Lisa R. 
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From: wingard (Drew Wingard) 

Sent: Wednesday, July 19, 1995 9:11 PM 

To: tbr 

Cc: bobm; craig; cronus; dickson 

Subject: Re: cronus cerberus regiters 0-5 


Tbr wrote: 

> Craig Hansen wrote (on Wed Jul 19) : 
> 

<snip> 

> 

> With the above information, I would use just a new manufacturer 

> code, which shall be (drum roll please) 0x0 0 40 a3 b4 ed fe. 
> 

> So octlet 2 changes from 0x00 40 a3 69 db 3f 01 0 0 

> to 0x00 40 a3 b4 ed fe 01 00. 
> 

> The manufacturer code should be distinct for each Cronos vendor, 

> to facilitate tracking, so if we are taping out to >1 vendor, 

> I'll assign some additional codes. 
> 

> That presents us with an additional challenge. My understanding is 

> the current plan is to tape out identical masks to the two vendors 

> (geert can you comment on this please) . Although it would logically 

> be a trivial change to have this number different between the two and 

> a valuable feature to help track things after fab and packaging, 

> having to handle two independent tapouts may add an unacceptable delay 

> to one of them, at least for the first version. We are assigning two 

> different part numbers because there are physical differences (such as 

> wafer thickness) which affect the packaging. 
> 

> Tim 

We can't tape out * identical* masks to our two foundries for a couple of 
reasons : 

1. Different design rules 

2 . Different layer names 

3 . Different layer biases/fields 

We'll need to at least have separate fracturing flows. I would claim that we really have 
two tapeouts. Since we know which vendor has better turnaround time (and better yield), I 
think that we know which one to tapeout first. 

Regards , 
Drew 
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From: tbr (Tim B. Robinson) 

Sent: Wednesday, July 1 9, 1 995 8:33 PM 

To: craig (Craig Hansen) 

Cc: bobm; cronus; dickson 

Subject: Re: cronus cerberus regiters 0-5 


Craig Hansen wrote (on Wed Jul 19) : 

> From dickson Tue Jul 18 12:04:25 1995 

> Return- Path: <dickson> 

> Received: from gamorra.microunity.com by mnemosyne.microunity.com (8 . 6 . 10/muse-sw. 3 ) 

> id MAA05939? Tue, 18 Jul 1995 12:04:24 -0700 

> Received: by gamorra.rnicrounity.com (8 .6 . 10/muse-sw.3) 

> id MAA27963; Tue, 18 Jul 1995 12:04:23 -0700 

> Date: Tue, 18 Jul 1995 12:04:23 -0700 

> From: dickson (Richard Dickson) 

> Message-Id: <199507181904 .MAA2 7 963@gamorra .microunity.com> 

> To: craig 

> Subject: cronus cerberus regiters 0-5 

> Status: RO 
> 

> craig 
> 

> What's the current level of compatibility between cronus and euterpe? 
> 

> we're mapping euterpe directly with the exception of 'knob stuf ' 

> so i dont think anything at the micro -arch level is differnent 
> 

> it should be a cmos copy of the eel euterpe design. 

> 
> 

> dickson 


With the above information, I would use just a new manufacturer 
code, which shall be (drum roll please) 0x00 40 a3 b4 ed fe. 

So octlet 2 changes from 0x0 0 40 a3 69 db 3f 01 00 
to 0x00 40 a3 b4 ed fe 01 00. 

The manufacturer code should be distinct for each Cronos vendor, 
to facilitate tracking, so if we are taping out to >1 vendor, 
I'll assign some additional codes. 

That presents us with an additional challenge. My understanding is the current plan is to 
tape out identical masks to the two vendors (geert can you comment on this please) . 
Although it would logically be a trivial change to have this number different between the 
two and a valuable feature to help track things after fab and packaging, having to handle 
two independent tapouts may add an unacceptable delay to one of them, at least for the 
first version. We are assigning two different part numbers because there are physical 
differences (such as wafer thickness) which affect the packaging. 

Tim 
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From: 
Sent: 
To: 

Subject: 


tbr 

Tuesday, July 18, 1995 12:40 AM 
Tom Eich 

5V not required for Cronus in Pandora? 


Tom Eich wrote (on Mon Jul 17) : 

I'm just sending this to you as I'm fuzzy on the firmness of our commitment 
to using a 3,3V process for Cronus , and therefore our elimination of the 5V 
bus on the bus bar (we already have the extra two contacts on the Eicon 
connector on each Hermes module- -should we revisit that?) . Please let me 
know what the direction is here, and if you think we need to make a 
"decision" message relative to the power subsystem. 

5V is required. The initial tapeout is to TSMC and CSM in each case to a 0 . 6u 5V process. 
The part should also be operational on 3.3V, at reduced speed/power, but we do not want to 
operate in that mode in Pandora. We have also discussed a followup version to a 0 . 5u 
process which would be 3.3V only, but we have no serious plan in place for that and my 
guess is that the resources will go into a completely new design rather than a redesign of 
Cronus . 


Tim 
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From: 
Sent: 
To: 

Subject: 


jack {Jack Wenstrand) 
Monday, July 17, 1995 8:34 PM 
cronus 


Foundry Data/New WWW page 


To : Cronus 


The foundry pages on the Web (chip->cronus->process) have been updated. News includes: 

- new versions of CSM 0 . 6 urn 3LM 5V design rules and 
mask tooling data on 6/27. 

- CSM will give us E-test structure data. 

- We will tape out in MEBES format to both foundries. 

- CSM is coming up the yield curve, but would have 
some trouble with our large die size if we taped out 
today . 

- TSMC has a 0.5um, 3.3V process available. We have 
design rules and other documents. 

The WWW pages include contacts, a list of documents on file, status, and meeting minutes. 


Regards , 
Jack 
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From: 
Sent: 
To: 

Subject: 


vanthof (vant) 

Saturday, July 15, 1995 2:07 AM 

lisar; tbr; technology-checkins-dist; torn; vanthof 

technology/mobimos/iss abs34_waf.vc abs23_drc.vc abs34_drc.vc contped_drc.vc 
contped__grow.vc contpedjwaf.vc defmes.h metaf1_drc.vc metal 1_perf.vc metal1_waf.vc 
metaf2_perf.vc metal2_waf.vc metal3_drc.vc metal4_drc.vc metal4_perf.vc metaW_waf.vc 
mobidrd 


Update of /p/cvsroot /technology/mobimos/iss In directory 
hestia : /N/rama/s4/vanthof /chip/technology/mobimos/iss 

Modified Files: 

abs23_drc.vc abs34drc.vc contped_drc . vc contped_grow. vc 
contped_waf . vc defines. h metall_drc . vc metall_perf . vc 
metal l_waf .vc metal2_perf . vc metal2_waf . vc metal3_drc . vc 
metal4_drc.vc metal4_perf . vc metal4_waf . vc mobidrclmaster . vc 
mwap_drc . vc vial2__grow. vc vial2_perf . vc vial2_waf.vc 

via23_grow. vc via34_grow. vc via45_grow. vc via45_perf . vc Added Files: 
abs34_waf . vc 
Log Message: 

clean up abs comments. Differentiated between tapeout and not for abs checks, 
changed via growing from 5 udrs to 4 udrs to help put things back on grid and to keep 
metals from getting 'wide 1 


Exhibit C16 


Page 79 of 12 


Subject: 


From: 
Sent: 
To: 

Cc: 


wingard (Drew Wingard) 
Friday, July 14, 1995 5:01 PM 
woody 
geert; tbr 

Re: cronus homepage 


Jay sez : 

> The theory behind the cronus homepage is good, the only problem is 

> that there is a lot of useless information. For example the logic 

> mapping process flow-chart is helpful, whereas the information for most of the 'Custom 
Blocks 1 

> is useless, is the intention to eventually (i.e. before tapeout) 

> update the appropriate pages? 


If I had a big enough stick. . . 

I would very much like to get the documentation system into a better state. 

I spent a fair amount of time getting it to where it is, and I think it's pretty usable 

and user- friendly. 

Now we just need to convince our designers to ENTER THE DATA. 

I think that one of the things we really should do is highlight some of the differences 
between Cronus and Euterpe, while we still remember them! 

I look forward to your first addition. 


> 


> thanks, 

> woody 


Drew 
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From: Derek Iverson [doi] 

Sent: Friday, July 14, 1995 12:45 PM 

To: pandora; hestia 

Subject: Software Bringup Meeting Minutes - July 12, 1995 


The first thing you may notice is that the published format of these minutes has 
changed. . . . 

The time of future Software Bringup meetings has been changed to 3:00pm from the previous 
time of 2 : 00pm. 

Lisar commented that she was able to build the OSF kernel and was in the middle of running 
it on the IKOS. 

Ethan has modified the software simulator to reflect the power-on state of cerberus 
registers . 

Jeffm posted a note to the euterpe group summarizing his investigation into why the 
software and hardware simulators got such varying run times for the regdepend tests. Here 
is a summary of his findings (I sucked these lines out his posting to muse. euterpe ) . 

There are three differences that I have noticed so far: 

1: terp does not get a hazard when the pre-event 
pc is stored to right before the bback (same 
cyl) . The store issues ten minor cycles before the 
bback issues . The hw hiccups . 

2. terp models exception entry as taking 13 major 
cycles. The average seems to be a bit higher (15). 

3 . terp does not model the effect of if etch page 
crossing <a mid- pipe hiccup that causes a 4 (?) 
major cycle interruption in instruction flow) . The 
i fetch page size is the minimum (64bytes) . 

Unfortunately there are still differences beyond 
these, but I haven't tracked them down. The above 
three account for 80% of the difference in event 
handling timing, however. 

The majority of the meeting was spend reviewing items on the Pandora bringup schedule. 

The software group will be able to make use the CBI device 
as early as Aug 4. 

If we want to have gdb to work with the HW simulators we 
will need to add hostio support to snoopy as well as decide 
what kind of interface snoopy will provide to gdb. In 
particular, should it have an interface similar to the 
CBI device driver? 

Here is an attempt of representing the pieces of the gdb puzzle with an ascii diagram.... 

/ I hostio I I 

/ I — I 

socket / | HWTERP | 

/ 

/ 

/ 
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/ socket 


| GDB | 


\ 

\ 

\ 


cbi daemon 



cbi device driver 
and hostio 


X8S PC 


socket \ 


| cbi card | 


| cerberus bus 


| hostio | 


PANDORA | 


snoopy | sdram 


HW SIMULATOR 


Using this configuration we will be able to 

o reset devices using either a cerberus reset or 

writing the reset bit. 
o load executables 
o causes a logic clear 

o get status from the print, status, and end octlets 


It should also be noted that a special gdb stub will be required to enable remote 
debugging. This stub is loaded and run on euterpe and will handle all interactions with 
the user's gdb session. 

During the very initial stages of bringup on the actual hardware, this gdb stub will not 
be used but instead the CBI device driver will be instructed to present a particular load 
image on a given cerberus address space. The remote machine will then boot this image and 
report it's status by using the print, status, and end octlets. 

After the meeting Jeff and I were thinking it might be nice for the CBI device driver to 
understand and use what we in verification refer to as a "cerb.in' file. This discussion 
will likely happen in the week prior to our next meeting . 

We need to start filling in the plan for hardware, software, and mechanical bringup 
activities in the proposed bringup areas. 

That is it for now. 


in cerberus space 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Wednesday, July 12, 1995 6:34 PM 
hardheads 

vanthof (Dave Van't Hof) 
minor bug fixes in mobi drc flow 


There have been a few reported false errors with the previous mobimos drc flow. 

- max metal4 space 

- via45 offgrid 

- via34 support by metal3 

These have been fixed. 

A significant change in how wide metals are handled in the drc flow has been turned on 
with the latest release- At tapeout, we perforate all wide metals with a 'basket weave' 
pattern of 1 . 5x4 . 5 micron holes . There are cases where the perforation cannot be achieved 
because of interactions with below and above layers. The drc flow now perfs all wide 
metals (Greater than 

4.5 microns) and then does a maximum metal width check. There will be errors 
generated in the current layouts. We cannot guarantee 100% perfect 

perforation and by putting this in the drc flow, we will find out early (before tapeout) 
and fix them. 

A minor note about the new qdrc script. This script runs the _exact_ same drc flow as 
rdrc does, but without the 14 dracula checks. 

If any new problems or questions come up about the new drc flow, please let me know. 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender 1 I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 


Thanks 
Dave 
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Subject: 


Sent: 
To: 

Cc: 


From: 


jack (Jack Wenstrand) 

Wednesday, July 12, 1995 6:16 PM 

tony; geert; tbr; bill; al; wingard; todd@nara.com 

jack; mouss 

Cyrix Meeting Agenda 


Here is the final agenda for the Cyrix meeting tomorrow. 

Regards , 
Jack 


Logistics : 
War Room 
3:00 - 

Thursday, July 13, 1995. 

Attendees : 
Cyrix : 

Kevin McDonough, VP Engr. 
?, CAD Mgr. 
MU: 

Drew, Tony, Geert, Tim, Bill, Al 
Todd Morgenthaler 

Background: 

Cyrix has their own x86 designs, currently being fabbed by SGS Thomson and IBM. They 
are using IBM's CM4LC 0.6 um process (their die is now 3 94 mm2 in this 

process) and moving to the CM5S 0.5 um process. This process has a 1.2 um metal pitch at 
metal one, and 1.8 um for 2-4. 

A previous meeting with Steve Domenik of Cyrix has created some interest. Kevin will 
want to evaluate our technical merit. 


Send them home understanding that our technology could put them ahead of Intel . They 
should understand that Mobimos offers a significant performance boost for their processor 
over any other technology available in the near future, and that we have a road-map to 
stay ahead. 


While you are welcome to attend the entire meeting, you are welcome to conserve time by 
only attending the sections for which your name appears below. 

3:00 Tony 

Review agenda 

Overview of the microunity story. 
Key process performance metrics. 
Euterpe plot. Transistor counts. 


Objective : 


Agenda : 


3:20 


Al 

Mobimos, dense and fast. 


3:50 


Bill 

Mobimos circuit family. 


4:20 


Tim 

CAD and methodology. 


4:40 


Tim, Geert, Drew 

Review of Cyrix needs, methodology, and 
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die plots . 
5:30 Discussion 
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Sent: 

To: 

Cc: 


Subject: 


From: 


stick (Bruce Bateman) 
Wednesday, July 12, 1995 6:05 PM 
bill; wingard 

geert; manser; mouss; tbr 

Re: draper/issc panel interconnect nightmare 


> Date: Wed, 12 Jul 1995 15:47:42 -0700 

> From: wingard (Drew Wingard) 

> To: bill 

> Subject: Re: draper/issc panel interconnect nightmare 

> Cc: geert, manser, mouss, stick, tbr 

5» 

> Bill wrote: 

> > i just got a call from don draper. . he is on isscc program committee 

> > and is trying to put a panel together titled "interconnect nightmare". 

> > 

> > . . <snip> 

> 

> 

> Au contraire. I suggested at the ISSCC committee meeting that Don 

> call MicroTJnity precisely because I thought that : 
> 

> 1. We have an interesting solution to the "interconnect nightmare". 

> 2. A couple of SEM's of 4+1 layer lum pitch airbridged gold (built using .5um 

> lithography) would give the designers in the crowd the impression that 

> MicroUnity offers some die -and- wake -up- in- heaven process technology to 

> work with. In other words, it could help us staff our future projects. 

> We won't get many opportunities to try and attract circuit/logic designers 

> by showing them our process, since most circuit-oriented technical forums 

> focus on circuits, not the underlying technologies. 


I would totlly agree - IF we could be confident that we'd have it up and running in some 
form or another by then. But realistically speaking, this would be a gamble. We could 
very easily end up spending the next six months just concentrating on getting the non-air- 
bridge metal working well enough that we can produce and debug caliope/euterpe/mnemo/etc . 
I suspect that air-bridge will have to remain on the back burner until then. And then we 
could spend months trying to get it to work. Thus, it may not be there yet come next 
February . 


> 


> 


Regards , 
Drew 


BB 
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\ 


From: 
Sent: 
To: 

Subject: 


lisar (Lisa Robinson) 

Tuesday, July 11, 1995 10:25 PM 

manser; geert; tbr; drew; hopper; mudge; jack 

cronus schedule in your mailbox 


I have place a (somewhat recovered!) cronus schedule in your mailboxes. It has been 
filtered upon "not completed" . If there are tasks that have been completed, let me know. 
I have levelized the schedule but selectively, most tasks are not prioritized. 
I was reluctant to distribute a schedule that had had the delay removed since there were 
so many overallocations of resources which gave an unrealistic tapeout date (with the 
current resources) . 

This is something that we should discuss tomorrow. 


Lisa R. 
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Sent: 

To: 

Cc: 


Subject: 


From: 


wampler {Kurt Wampler) 
Tuesday, July 11, 1995 1:16 PM 
tbr 

geert; vanthof 
Re: Full chip LVS 


tbr writes: 


>Concensus seems to be we should attempt another euterpe full chip LVS. 
>I have a version of the route completed in the snapshot area. It's not 
>as good from a timing perspective as the one I have locally, but it has 
>been built using the latest snapshot proteus and the newly updated 
>snapshot euterpe, so I would recommend we work from that one. 
>lt has order 55 dicsonnects which would need to be completed. 
> 

>Kurt, can you attempt that please? There should be a corresponding 
>splvs netlist already there. 

I will try to route it to completion. Can you give me an idea of 
how careful I should be? Since the baseplate itself is undergoing 
edits, I suspect that we wouldn't tape out from this route? 

>ln addition to just making the remaining hookups, can you form some 
>assesment of how difficult these are and what the expected additional 
> impact on bad timing paths would likely be? 

This depends too on how careful I am. (For example, whether I am 
permitted to use the rip -up router, or whether I have to hand rip 
and guarantee that no net I rip and put back gets worse.) 

>ln my local area I have som experimental changes which may improve 
> things further and I will press ahead there without touchin the 
>snapshot for a while. 


- Kurt 
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From: lisar (Lisa Robinson) 

Sent: Monday, July 10, 1995 3:54 PM 

To: manser 

Cc: geert; hooper; jack; tbr 

Subject: Cronus schedule 


The last level I performed on the schedule pushed the tapeout date to 20491 There appears 
to be no reason for this (other than corruption) and indeed taking out the delay doesn't. 
It will take me a while to recover. 

Lisa R. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr 

Sunday, July 09, 1995 8:21 PM 
hopper (Mark Hofmann) 
geert (Geert Rosseel); vant 
Re: Euterpe timing status 


Mark Hofmann wrote (on Sun Jul 9) : 


Tim B. Robinson writes: 

Just a brief update on the current status of the euterpe physical 
design. 


Our best routing result to date is such that by manually adjusting 
about 10 paths we can get within 200ps of the magic GHz based on our 
current best models. We are continuing to work this by running 
additional timing optimization/ routing iterations while we wait for 
the DRC rules and fracture flow to be finalized. 

At that point we will not delay the first tapeout based on any 
remaining timing violations. 

Definitely worth menitoning! 


Is your feeling that you would like to try a few more iterations/ experiments 
before we do another round of LVS? Would it be worth connecting up the 
disconnects sloppily in order to run an LVS just to check things? 

It would be worth a check. Also to see how horrendous the remaining 

55 are. I have a run going in the snapshot. Should be out sometime during the night. 
It's off the same version as my last run in my area except that it does not have the -U 
topt flag so I'm expecting it to be worse. 

I believe there is still, perhaps considerable, DRC work to be done on 
Euterpe. The amount of DRC work depends to what rules we decide we want 
to tape out to. 


Tim 


-hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tor 

Sunday, July 09, 1995 8:19 PM 
hopper (Mark Hofmann) 

billz (Bill Zuravleff); dickson (Richard Dickson); geert (Geert Rosseel); lisar (Lisa Robinson); 
mws (Mark Semmelmeyer); wampler (Kurt Wampler); woody (Jay Tomlinson) 
Re: latest route 


Mark Hofmann wrote (on Sun Jul 9) : 

Tim B. Robinson writes: 

The 4th iteration completed. Violations down again to 291 paths (from 
3 SO last time) . Worst case is off by 140 Ops, but fixing the 10 worst 
paths would get us within 200ps. There were 55 diconnects. 

Better and better! 

What about the first derivative of the number of timing violations? Is it 
beginning to taper off? 

3600, 1600, 1200, 360, 291 

Theres a lot of fluctuation. I could be tempted to draw a stright line saying it goes 
down by 1/2 each time on average . . . 


Tim 


Exhibit C16 


Page 91 of 128 


Sent: 

To: 

Cc: 


From: 


Subject: 


hopper (Mark Hofmann) 
Sunday, July 09, 1995 1 1:00 AM 
Tim B. Robinson 
vant; geert (Geert Rosseel) 
Re: Euterpe timing status 


Tim B. Robinson writes: 

Just a brief update on the current status of the euterpe physical 
design. 


Our best routing result to date is such that by manually adjusting 
about 10 paths we can get within 2 0 Ops of the magic GHz based on our 
current best models. We are continuing to work this by running 
additional timing optimization/routing iterations while we wait for 
the DRC rules and fracture flow to be finalized. 

At that point we will not delay the first tapeout based on any 


Is your feeling that you would like to try a few more iterations/experiments before we do 
another round of LVS? Would it be worth connecting up the disconnects sloppily in order to 
run an LVS just to check things? 

I believe there is still, perhaps considerable, DRC work to be done on Euterpe. The amount 
of DRC work depends to what rules we decide we want to tape out to. 



violations. 


Definitely worth menitoningJ 


Tim 


-hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Sunday, July 09, 1995 10:52 AM 
Tim B. Robinson 

lisar (Lisa Robinson); sysadm; vant; wampler (Kurt Wampler) 
Re: /n/tmp 


Tim B. Robinson writes: 
Yes. 

It has been planned to move it there for a long time, but with the 
availability problem of the drives a while back we did not do it. 
Ken has said he will do it this week. 

Great! I think we will realize an immediate benefit with this. 

You may remember before the 

most recent crunch, we almost did it but ran into the technical 
consideration of how to do it without disrupting things that were 
actively using it. This time I think we just bite the bullet, say 
when, and move it. It may make sense to to co-ordinate this with the 
planned upgrade installation. 

Hmm. . True. Do we have an official date/time for that now? I recall it was to be a 
Thursday evening about 2 weeks (1 week now?) hence. 

As regards Disksuite, the Auspex has had that funtionality and more 
since inception (ie virtual partitions, striping, mirroring etc) . 

The reluctance to go to truly huge patitions (we now use 4.5GB as the 
standard) is because of backup and restore issues and how long we 
would want a substantial number of users to be down after a major 
failure. You may remember the one time we did have a drive failure 
3 0 users were down about 24 hours, though much of that should have 
been unneccesary had we been better prepared (I think we now are) . 

Right. Though I was thinking about a large /tmp partition where we would not have 
backup/restore issues, having large partitions everywhere would be a real boon for disk 
management . 

Later this year auspex should be releasing software which will offer 
true raid capabilities which would reduce this consideration since a 
single drive failure would not then require any tapes to be visited. 
They have not given a release date yet, but we did make budget 
provision for this. 

Very good . 

I beleive the Alpha system offers something like this, though I'm unclear on the details. 


Tim 


-thanks, 
hopper 
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From: 
Sent: 
To: 

Subject: 


tbr (Tim B. Robinson) 

Sunday, July 09, 1995 11:38 AM 

euterpe 

Euterpe timing status 


Just a brief update on the current status of the euterpe physical design. 

Our best routing result to date is such that by manually adjusting about 10 paths we can 
get within 200ps of the magic GHz based on our current best models, "We are continuing to 
work this by running additional timing optimization/routing iterations while we wait for 
the DRC rules and fracture flow to be finalized. At that point we will not delay the 
first tapeout based on any remaining timing violations. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


for 

Sunday, July 09, 1995 11:12 AM 
hopper (Mark Hofmann) 

tisar (Lisa Robinson); sysadm; vant; wampler (Kurt Wampler) 
/n/tmp 


Mark Hofmann wrote (on Sun Jul 9) : 


Hi, 


Isn't the bottom line on all this that /n/tmp ought really to be on the 
auspex? /n/tmp on rama has served us well to this point, but the Auspex is 
better set up to deal with lots of large data requests as a disk server. 
And disk is cheap enough that we ought to consider using Auspex disk for 
this tmp function. BTW: can we put DiskSuite on the Asupex? 


It has been planned to move it there for a long time, but with the availability problem of 
the drives a while back we did not do it. 

Ken has said he will do it this week. You may remember before the most recent crunch, we 
almost did it but ran into the technical consideration of how to do it without disrupting 
things that were actively using it. This time I think we just bite the bullet, say when, 
and move it. It may make sense to to co-ordinate this with the planned upgrade 
installation. 

As regards Disksuite, the Auspex has had that funtionality and more since inception (ie 
virtual partitions, striping, mirroring etc) . 

The reluctance to go to truly huge patitions (we now use 4.5GB as the 

standard) is because. of backup and restore issues and how long we would want a substantial 
number of users to be down after a major failure. You may remember the one time we did 
have a drive failure 3 0 users were down about 24 hours, though much of that should have 
been unneccesary had we been better prepared (I think we now are) . 

Later this year auspex should be releasing software which will offer true raid 
capabilities which would reduce this consideration since a single drive failure would not 
then require any tapes to be visited. 

They have not given a release date yet, but we did make budget provision for this. 


Yes. 


Tim 
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From: 
Sent: 
To: 

Subject: 


geert (Geert Rosseel) 
Friday, July 07, 1995 8:57 AM 
pollux 

Pollux Status + Meeting 


Hi, 


Can we get together today at 
Hopper) ? 


2:00 to discuss Pollux status (Conference Room next to 


I ran LVS and DRC on all released modules in /u/chip 


LVS 


modi 
mod2 
mod3 
raod4 : 
mod5 
mods 
mod 7 
mod 8 
mod 9 
modlO 
modll 
modi 2 


: cap mismatches 

: clean 
clean 
clean 

: cap mismatches 
8 un- matches devices 
7 un-matches devices, 
lot 1 s of errors 
clean 
clean 
clean 
clean 


substrate problem 


DRC is still running : here are the partial results 


-rw-rw-rw- 
-rw-rw-rw- 
-rw-rw- rw- 
-rw-rw-rw- 
-rw-rw-rw- 
-rw-rw-rw- 


geert 
geert 
geert 
geert 
geert 
geert 


41178 Jul 
10973 Jul 
16998 Jul 
79717 Jul 
184504 Jul 
12607941 Jul 


:56 modi. err 

:49 mod2.err 

:46 mod4.err 

:46 mod5. err 

06:13 mod6. err 

04 :32 raod7.err 


02 : 
02 : 

02 : 

03 : 


LVS is a very high priority 
path to tape-out . . . 


Toplevel LVS is a critical 


Arya and Rich/Mudge : can you work on 6,7 today, 
mod6/mod7 problems may be due to un- released layouts. 
Please check solo's list of un-released layouts (on Mosaic), 


DRC 


is looking not too badly again 


obviously : mod7 needs immediate attention. 
Rich, Mudge : do you need layout help on this ? 

Can we get this started early this morning. ? 


All results are in 
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/u/geert/compass/polluxrel 

Geert 
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From: paulp (Paul Poenisch) 

Sent: Thursday, July 06, 1 995 1 :39 PM 

To: geert (Geert Rosseel); tbr (Tim B. Robinson); vanthof (Dave Van't Hof); wampler (Kurt 

Wampler); hopper (Mark Hofmann); torn (Tom Laidig) 
Subject: Re: backend tapeout questions 


It looks like everyone can make it at 1:00 today. Kurt did say that he would have to 
leave a 1:30 but hoepfully we can get all the issues on the table 
before he has to go. So let's meet today at 1:00 in the west hardware 
engineering conference room. 

Paul. 
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Subject: 


Sent: 
To: 

Cc: 


From: 


torn (Tom LaicNg [tau]) 
Thursday, July 06, 1995 11:12 AM 
Paul Poenisch 

geert (Geert Rosseel); hopper (Mark Hofmann); warn pier (Kurt Wampler); vanthof (Dave Van't 
Hot); tbr (Tim B. Robinson); tau 
Re: backend tapeout questions 


Paul Poenisch writes: 

It looks like most people can make A meeting at 4:00 today (I haven't 
heard from everyone yet but sofar no one has had a problem with that time) . 
However Tim has suggested that we have it at 1:00 rather than 4:00, I 
would prefer it earlier if possible. Let's plan on 4:00 but if 
everyone is avialable at 1:00 I would like to move it to that time. If 
you don't here from me it will be at 4:00 (in the hardware engin. west room). 

1PM is good for me. 4PM is OK, but I want to leave not much later than 5. 
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From: vanthof (vant) 

Sent: Thursday, July 06, 1 995 1 1 :02 AM 

To: Mark Hofmann 

Cc: tbr (Tim B. Robinson); hopper (Mark Hofmann); wampler (Kurt Wampler); torn (Tom Laidig); 

vanthof (Dave Van't Hof); geert (Geert Rosseel) 
Subject: Re: backend tapeout questions 


Mark Hofmann writes: 
> 

>Paul Poenisch writes: 
> 

> It looks like most people can make a meeting at 4:00 today (I haven't heard 

> from everyone yet but sofar no one has had a problem with that time) . 

> However Tim has suggested that we have it at 1:00 rather than 4:00, I would 

> prefer it earlier if possible. 

> Let's plan on 4:00 but if everyone is avialable 

> at 1:00 I would like to move it to that time. If you don't here from me it 

> will be at 4:00 (in the hardware engin. west room). 
> 

> Paul . 
> 

>lp is fine with me. 


lpm is fine with me too. 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . n The Tick to Thrackazog 
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From: hopper (Mark Hofmann) 

Sent: Thursday, July 06, 1 995 4:00 AM 

To: Paul Poenisch 

Cc: tbr@microunity.com; geert (Geert Rosseel); torn (Tom Laidig); wampler (Kurt Wampler); 

vanthof (Dave Van't Hof) 
Subject: Re: backend tapeout questions 


Paul Poenisch writes: 

It looks like most people can make a meeting at 4:00 today (I haven't heard 
from everyone yet but sofar no one has had a problem with that time) . 
However Tim has suggested that we have it at 1:00 rather than 4; 00, I would 
prefer it earlier if possible. 

Let's plan on 4:00 but if everyone is avialable 

at 1:00 I would like to move it to that time. If you don't here from me it 
will be at 4:00 (in the hardware engin. west room). 

Paul. 

lp is fine with me. 
-hopper 
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Subject: 


Sent: 
To: 

Cc: 


From: 


paulp (Paul Poenisch) 
Thursday, July 06, 1995 10:25 AM 
Tim B. Robinson 

geert (Geert Rosseel); hopper (Mark Hofmann); torn (Tom Laidig); wampler (Kurt Wampler); 

vanthof (Dave Van't Hof) 

Re: backend tapeout questions 


It looks like most people can make a meeting at 4:00 today (I haven't heard from everyone 
yet but sofar no one has had a problem with that time) . 

However Tim has suggested that we have it at 1:00 rather than 4:00, I would prefer it 
earlier if possible. Let r s plan on 4:00 but if everyone is avialable at 1:00 I would like 
to move it to that time. If you don't here from me it will be at 4:00 (in the hardware 
engin. west room) . 


Paul . 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr 

Wednesday, July 05, 1995 10:01 PM 
paulp (Paul Poenisch) 

geert (Geert Rosseel); hooper; torn (Tom Laidig); vanthof (Dave Van't Hof); Kurt Wampler 
Re: backend tapeout questions 


Paul Poenisch wrote (on Wed Jul 5) : 

It looks like tomorrow morning is out due to staff meetings and other problems. 
Also early afternoon is out due to a meeting with photonics. I have an 
interview from 3:15 to 4:00 so it looks like the earliest we could do it is 
at 4:00 tomorrow. Can everyone make this time? 

I can, but I still thing 1-2 ought to be a viable alternative. 


Tim 


Exhibit C16 


Page 103 of 128 


Subject: 


Sent: 

To: 

Cc: 


From: 


tor 

Wednesday, July 05, 1995 10:00 PM 
wampler (Kurt Wampler) 

geert; hopper; paulp@microunity.com; torn; vanthof 
Re: backend tapeout questions 


Kurt Wampler wrote (on Wed Jul 5) : 
Dave writes: 

>I would like to have Geert and Tim at the meeting so they have some incling 

>as to the backend synthesis process. 

> 

>How about 1:30 tomorrow? 

1:30 is perilously close to a 2PM that I'm supposed to attend at Photronics 
tomorrow with Jack Wenstrand. Late morning, or later in the afternoon fits 
better with my schedule. 

Let's move it up to 1 and keep it to an hour. 

Tim 
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From: paulp (Paul Poenisch) 

Sent: Wednesday, July 05, 1995 8:15 PM 

To: Kurt Wampler 

Cc: geert (Geert Rosseel); tbr (Tim B. Robinson); torn (Tom Laidig); vanthof (Dave Van't Hof); 

hooper 

Subject: Re: backend tapeout questions 


It looks like tomorrow morning is out due to staff meetings and other problems. 
Also early afternoon is out due to a meeting with photonics. I have an interview from 
3:15 to 4:00 so it looks like the earliest we could do it is at 4:00 tomorrow. Can 
everyone make this time? 

Paul. 
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Subject: 


From: 
Sent: 
To: 
Cc: 


wampler (Kurt Warn pier) 
Wednesday, July 05, 1995 7:21 PM 
paulp@microunity.com; vanthof 
geert; hopper; tbr; torn 
Re: backend tapeout questions 


Dave writes: 


>I would like to have Geert and Tim at the meeting so they have some 

>incling as to the backend synthesis process. 

> 

>How about 1:30 tomorrow? 

1:30 is perilously close to a 2PM that I'm supposed to attend at Photronics 
tomorrow with Jack Wenstrand. Late morning, or later in the afternoon fits 
better with my schedule . 


- Kurt 
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Sent: 
To: 

Cc: 


Subject: 


From: 


vanthof (vant) 

Wednesday, July 05, 1995 6:27 PM 
Paul Poenisch 

tbr (Tim B. Robinson); torn (Tom Laidig); wampier (Kurt Wampler); hopper (Mark Hofmann); 
geert (Geert Rosseel); vanthof (Dave Van't Hof) 
Re: backend tapeout questions 


Paul Poenisch writes: 

>Thrusday morning would be OK with me if the meeting is over before 
>10:00, I have a Castor2 meeting then. Also for my purposes I suspect 
>that Geert and you don't need to be a this meeting as what I would like 
>to get out of the meeting is an understanding of how the post 
>processing is to be done (as currently planned) rather than making any 
>decisions about it. However it's likely that others will want 

>different issues and topics discussed, if that's the case then maybe it should be moved 
to Thursday. 


Sorry for the delay in getting back to you on this. 

I usually don't get in until 9:30 now, plus there are two staff meetings tomorrow morning: 
tbr's, then hopper's starting at 9:30. 

Mornings are never very good for me. 

I would like to have Geert and Tim at the meeting so they have some incling as to the 
backend synthesis process. 

How about 1:30 tomorrow? 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender I I mean, I know it, I'm not dumb... just 
not in this context . ■ The Tick to Thrackazog 


> 


>Paul . 


> 
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From: paulp (Paul Poenisch) 

Sent: Wednesday, July 05, 1995 12:11 PM 

To: Tim B. Robinson 

Cc: torn (Tom Laidig); vanthof (Dave Van't Hof); hopper (Mark Hofmann); wampler (Kurt 

Warn pier); geert (Geert Rosseel) 
Subject: Re: backend tapeout questions 


> Tom Laidig [tau] wrote (on Wed Jul 5) : 
> 

> Paul Poenisch writes : 
> 

> I would like to meet sometime today to discuss the issues that Dave has 

> brought up. I'm open all day except at 4:00. 
> 

> Sounds good. I'd like to leave by 5 today (the roofers are ripping the 

> old roof of f my house today, and I want to sneak in some wiring work 

> tonight while the roof is out of the way), I'd prefer meeting before 4. 

> 

> Geert is out today and I suspect he'd be keen to participae in this 

> discussion so I wonder if it make more sense to schedule it for the 

> morning. 
> 

> Tim 


Thrusday morning would be OK with me if the meeting is over before 10:00, I have a Castor2 
meeting then. Also for my purposes I suspect that Geert and you don't need to be a this 
meeting as what I would like to get out of the meeting is an understanding of how the post 
processing is to be done (as currently planned) rather than making any decisions about it. 
However it's likely that others will want different issues and topics discussed, if that's 
the case then maybe it should be moved to Thursday. 

Paul. 
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Subject: 


From: 
Sent: 
To: 
Cc: 


tbr 

Wednesday, July 05, 1995 1 1:51 AM 
torn (Tom Laidig [tau]) 

geert (Geert Rosseef); hopper (Mark Hofmann); Paul Poenisch; tau; vanthof (Dave Van't Hot); 

wampler (Kurt Wampler) 

Re: backend tapeout questions 


Tom Laidig [tau] wrote (on Wed Jul 5) : 

Paul Poenisch writes: 

I would like to meet sometime today to discuss the issues that Dave has 
brought up. I'm open all day except at 4:00. 

Sounds good. I'd like to leave by 5 today (the roofers are ripping the 
old roof off my house today, and I want to sneak in some wiring work 
tonight while the roof is out of the way), I'd prefer meeting before 4. 

Geert is out today and I suspect he'd be keen to participae in this discussion so I wonder 
if it make more sense to schedule it for the morning. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


torn (Tom Laidig [tau]) 
Wednesday, July 05, 1 995 1 1 :43 AM 
Paul Poenisch 

vanthof (Dave Van't Hof); hopper (Mark Hofmann); tau; wampler (Kurt Wampler); geert (Geert 
Rosseel); tbr (Tim B. Robinson) 
Re: backend tapeout questions 


Paul Poenisch writes: 

I would like to meet sometime today to discuss the issues that Dave has 
brought up. I'm open all day except at 4:00. 

Sounds good. I'd like to leave by 5 today (the roofers are ripping the old roof off my 
house today, and I want to sneak in some wiring work tonight while the roof is out of the 
way) , I'd prefer meeting before 4. 
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From: paulp (Paul Poenisch) 

Sent: Wednesday, July 05, 1 995 11 :29 AM 

To: vant; hooper; torn (Tom Laidig); wampler (Kurt Wampler) 

Cc: geert (Geert Rosseel); tbr (Tim 8- Robinson) 

Subject: Re: backend tapeout questions 


I would like to meet sometime today to discuss the issues that Dave has brought up. I'm 
open all day except at 4:00. 

Paul. 
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From: vanthof (vant) 

Sent: Wednesday, July 05, 1 995 11 :28 AM 

To: Tom Laidig [tau] 

Cc: solo@microunity.com; hardheads; tau 

Subject: Re: new Ivs and drc flow installed (minor tweaks) 


Tom Laidig [tau] writes: 
> 

dave, take a look at /u/solo/test/compass/cerpokgen. err and 
ceinvS.err. these are not very complex and look as if the ml contact 
rule is not doing the right job. maybe you are doing drc checks after 
the 2udr shrink and these ar the "few" examples of the via and contact 
on the edge of fat metal?? it does happen quite a few places. 

let me know. 
> 

>Those are some of the "few 1 examples of contact on the edge of fat 
>metal. This sort of thing is sprinkled around in various places, but 
>hey, there was only one error flag in each of the cells you mentioned! 
>So far, the situations like this I've fixed have been pretty easy, at 
>least . 
> 

This is why the synthesis is part of the drc flow/ to catch and _fix_ these errors before 
tapeout . 


Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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From: 
Sent: 

To: 

Subject: 


tbr 

Monday, July 03, 1995 1:18 PM 
wampler (Kurt Wampler) 
Re: Tape shipment 


Kurt Wampler wrote (on Mon Jul 3) : 


>If the offices are still all dark at 11, I'll come down. 

>Just let me know. 

> 

>Tim 


An 11:10 survey of Juli, Grant, Jessica offices turned up no evidence of 
inhabitants -- all still dark. Sorry to provoke an unwanted commute. 

The tapes are about half done writing. Assuming trex stays up, they should 
still be done around noon. I'll eat lunch here in the Cafe; I'll leave the 
package & tapes on my desk. Any time before 3PM is fine. 

OK, no problem I'll leave shortly. 


Tim 
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From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 
Monday, July 03, 1995 1:14 PM 
tbr 

Re: Tape shipment. 


>lf the offices are still all dark at 11, I'll come down. 

>Just let me know. 

> 

>Tim 


An 11:10 survey of Juli, Grant, Jessica offices turned up no evidence of 
inhabitants -- all still dark. Sorry to provoke an unwanted commute. 

The tapes are about half done writing. Assuming trex stays up, they should 
still be done around noon. I'll eat lunch here in the Cafe; I'll leave the 
package & tapes on my desk. Any time before 3PM is fine. 


- Kurt 
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From: 
Sent: 
To: 

Subject: 


tbr 

Monday, July 03, 1995 12:17 PM 
wampler (Kurt Warn pier) 
Re: Tape shipment. 


Kurt Wampler wrote (on Mori Jul 3) : 
tbr writes: 


>Is Grant available? If not, let me know and I'll come in. It will 
>take about an hour. What time do you expect to be ready? 

Grant's, Jessica's, and Juli ' s offices are all dark as of 10AM this morning. 
I should have the tapes written and ready for approval by noon today. 
Photronics will be here at 3PM to have a short meeting and receive the 
tapes from us. Any time between noon & 3 would be fine. 

I could certainly put copies of all of the FrameMaker documents and label 
files where you could review them on-line, though I realize that wouldn't 
allow you to check the physical labels. Let me know if you think an 
"electronic review" would be good enough. 

If the offices are still all dark at 11, I'll come down. 
Just let me know. 


Tim 
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From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 
Monday, July 03, 1995 12:03 PM 
tbr 

Re: Tape shipment. 


tbr writes: 


>Is Grant available? If not, let me know and I'll come in. It will 
>take about an hour. What time do you expect to be ready? 

Grant's, Jessica's, and Juli ' s offices are all dark as of 10AM this morning. 
I should have the tapes written and ready for approval by noon today. 
Photronics will be here at 3PM to have a short meeting and receive the 
tapes from us. Any time between noon & 3 would be fine. 

I could certainly put copies of all of the FrameMaker documents and label 
files where you could review them on-line, though I realize that wouldn't 
allow you to check the physical labels. Let me know if you think an 
"electronic review" would be good enough. 


- Kurt 
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From: vanthof (vant) 

Sent: Sunday, July 02, 1 995 1:35 AM 

To: paulp (Paul Pbenisch); al (Albert Matthews) 

Cc: vanthof (Dave Van't Hof); hopper (Mark Hofmann); geert (Geert Rosseel); tbr (Tim B. 

Robinson); wampler (Kurt Wampler); torn (Tom Laidig) 
Subject: backend tapeout questions (1 more item) 


vant writes: 
> 

> 1) wide metal shrinking 
> 

> 2) notch filling 
> 

> 3) via growing 

> 

> 4) via waffling 
> 

> 5) removal of small waffles on metals (not vias) . Small is defined 

> as less than 1.5 x 1.5 microns. 

I'd like to add one more item: 

6) wide metal perforations 

During the wide metal perforation process , because of upper and lower 
layer interactions, we can easily create holes that are less than 
1.5x1.5 micron. If we are to meet the rule that no hole is less 
than 1.5 x 1.5 microns, then we can also create large sheets of 
metal which no holes at all. 

A quick summary of the drc errors we will CREATE as a result of the 6 items I've 
mentioned: 

- notches less than 1.5 microns 

- holes less than 1 . 5 microns 

- wide metals with no holes. 

- wide metals spaced .5 microns to other metals. 

- via layers with some dense and many sparse areas 

- metal layers with large unwaffled areas (if we remove all small 
waffle bars) 

- a non-drc issue is if we allow via growing, then there would 
be many .25 micron (or less) edges created. 

Comments? 
Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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From: 
Sent: 
To: 


Subject: 


hopper (Mark Hofmann) 
Saturday, July 01, 1995 6:14 PM 

paulp (Paul Poenisch); al (Albert Matthews); vanthof (Dave Van't Hof); geert (Geert Rosseel); 
torn (Tom Laidig); wampler (Kurt Warn pier); tbr (Tim B. Robinson) 
Re: backend tapeout questions 


Hi, 


I've done some snipping to shorten my reply... 


vant writes: 


Hello, 


There have been many discussions about what to do and not to do during 
our back end synthesis lately, especially because sisyphus allowed us to 
generate examples of some of the synthesis. I would like to come to some 
sort of finality on some of these so I can proceed with completing the 
metal synthesis flow. I'd like to list the items first, then list what 
I believe to be the issues for each: 


item 4) via waffling. Via waff line has added a level of complexity to 
the backend synthesis not quite imagined. The generation of waffles 
for vias (and contped) does make wafflizing the metals much more 
difficult and in some cases quite impossible to accomplish. There 
are going to be large areas where we cannot add any via waffles 
because of the dense metal routing. The wafflization will then 
create a layer which may have many large/small low density areas 
with many large/small densely waffled areas. By removing via 
waffling, the back end synthesis becomes a known problem with 
existing solutions and minimal amount of work to integrate into 
the existing backend flow. I still don't have a back end waffle flow 
for upper metals. I have not had enough time to work on it yet and 
at my current rate of progress could take many more weeks. 
In addition, we will have no way of verifying that the final back 
end metal pattern has not created a massive short since the resulting 
metal layers are far too large for any Ivs tool to handle. We will 
have to trust that mere humans have done it right. Very scary. 
Question is, do we still allow via waffles? 

My feeling here is that whatever we end up with must be checkable by machine. 
Our processing is too complex to allow it to go forward without a check on each mask mod 
step. At the moment we still perform XOR mask checks after we have done all our synthesis. 
We ship the masks and do this XOR check afterward. The point is we do feel it is necessary 
not to trust our tools inherently, we always want to be able to double check ourseleves if 
we can. 

I would like to come to some resolution on these question rather quickly 
so I know where to focus my efforts for the back end synthesis. 


[snip] 


Thanks, 
Dave 


-hopper 
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From: hopper (Mark Hofmann) 

Sent: Saturday, July 01 , 1 995 6:06 PM 

To: tbr (Tim B. Robinson) 

Subject: backend tapeout questions (fwd) 


Hi Tim, 

Because of a typo I'm not sure you got this mail, 
-hopper 


vant writes: 

Subject: backend tapeout questions 

To: paulp {Paul Poenisch) , al (Albert Matthews) 

Date: Sat, 1 Jul 95 21:48:57 PDT 

Cc: vanthof (Dave Van't Hof ) , hopper (Mark Hofmann), geert (Geert Rosseel) , 

torn (Tom Laidig) , wamplertbr 
X-Mailer: ELM [version 2.3 PL11] 


Hello, 

There have been many discussions about what to do and not to do during 
our back end synthesis lately, especially because sisyphus allowed us to 
generate examples of some of the synthesis. I would like to come to some 
sort of finality on some of these so I can proceed with completing the 
metal synthesis flow. I'd like to list the items first, then list what 
I believe to be the issues for each: 

1) wide metal shrinking 

2) notch filling 

3) via growing 

4) via waffling 

5) removal of small waffles on metals (not vias) . Small is defined 
as less than 1.5 x 1.5 microns. 


item 1) wide metal shrinking. it's pretty stable at this time, however, 
we are seeing many cases where after the edges has been pulled back 
on wide metals, there are 3 or 4 udr (.15 or .2 micron) deep notches 
less than 1.5 microns wide created. The problem occurs when we 
notch fill these in. By filling the notches, we can easily bring 
back the wide metal to eliminate the notch, however, there could 
be another piece of metal spaced .5 microns away from the filled 
edge . This would give us wide metal next to other metal spaced 
at .5 microns. This does happen as I've seen it in some of our 
cells. The question is, is the wide metal next to small metal okay 
in some cases? 

item 2) notch filling. The current notch filling algorithms will only 
fill notch areas which do _not_ have connecting layers above or below 
crossing into or totally inside the notch area. This is to prevent 
shorts from occuring. Because routing in via layers is legal and 
the spacing is only 5 udrs from via to metal (or metal to via) , and 
notches can go the entire width of the chip, we cannot property 
determine if all of the via crossing into the notch is electrically 
connected. Thus the notch algorithm will not put metal over the 


Exhibit C16 Page 119 of 12 


connecting layer. This could in fact create smaller notches and 
even small holes (holes as small as 8 x 24 udrs) . However, notches 
which no interactions with other layers will ge filled, only notches 
which have some interaction with the connection layer will have parts 
of that notch left open. The notch filling could create min spaces 
from wide metals to narrow metals. Question is, do we still want 
to fill notches/holes (NOTE: we cannot tell the difference between 
a notch and a hole) 

item 3) via growing. A review of the fractured data of sisyphus' contped 
layer revealed an edge pattern that was apparently not quite 
what was expected so no growing was performed on sisyphus. The 
results of growing other via layers will look just like sisyphus 1 ' 
contped layer. Question is, do we still want to do via growing? 

item 4) via waffling. Via waff line has added a level of complexity to 
the backend synthesis not quite imagined. The generation of waffles 
for vias (and contped) does make wafflizing the metals much more 
difficult and in some cases quite impossible to accomplish. There 
are going to be large areas where we cannot add any via waffles 
because of the dense metal routing. The wafflization will then 
create a layer which may have many large/ small low density areas 
with many large/small densely waffled areas. By removing via 
waffling, the back end synthesis becomes a known problem with 
existing solutions and minimal amount of work to integrate into 
the existing backend flow. I still don't have a back end waffle flow 
for upper metals. I have not had enough time to work on it yet and 
at my current rate of progress could take many more weeks. 
In addition, we will have no way of verifying that the final back 
end metal pattern has not created a massive short since the resulting 
metal layers are far too large for any lvs tool to handle. We will 
have to trust that mere humans have done it right. Very scary. 
Question is, do we still allow via waffles? 

item 5} removal of small metal waffles. X ran some small tests on sisyphus 
which removed small metall waffle bars (less than 1.5 x 1.5). This 
resulted in many large areas (11x18 microns) which had _no_ metal 
waffle bars. If we had waffled vial2 (like we will on euterpe) , 
then the number of small metal waffle bars removed would increase 
by some amount resulting in even large areas with no waffle bars 
added. We've now converted very dense metal layers into relativly 
sparse layers which will fail the current metal density checks. 
Question is, do we want to remove small metal waffle bars and create 
large unwaf fles areas in metals? 


I would like to come to some resolution on these question rather quickly 
so I know where to focus my efforts for the back end synthesis. 

Thanks , 
Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

,r I don 1 t know the meaning of the word surrender! I mean, I know it, I'm not 
dumb... just not in this context." The Tick to Thrackazog 
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From: vanthof (vant) 

Sent: Saturday, July 01, 1995 11:51 PM 

To: vant 

Cc: wampler (Kurt Wampler); tbr (Tim B. Robinson) 

Subject: Re: backend tapeout questions 


typo on the "to: 1 line prevented you guys from getting this... 
vant writes : 


>Hello, 

> There have been many discussions about what to do and not to do 
>during our back end synthesis lately, especially because sisyphus 
>allowed us to generate examples of some of the synthesis. I would like 
>to come to some sort of finality on some of these so I can proceed with 
completing the metal synthesis flow. I'd like to list the items first, 
>then list what I believe to be the issues for each: 

> 

> 1) wide metal shrinking 
> 

> 2) notch filling 
> 

> 3 ) via growing 

> 

> 4) via waffling 
> 

> 5) removal of small waffles on metals (not vias) . Small is defined 

> as less than 1.5 x 1.5 microns. 


>item 1) wide metal shrinking. it's pretty stable at this time, however, 

> we are seeing many cases where after the edges has been pulled back 

> on wide metals, there are 3 or 4 udr (.15 or .2 micron) deep notches 

> less than 1.5 microns wide created. The problem occurs when we 

> notch fill these in. By filling the notches, we can easily bring 

> back the wide metal to eliminate the notch, however, there could 

> be another piece of metal spaced . 5 microns away from the filled 

> edge . This would give us wide metal next to other metal spaced 

> at .5 microns. This does happen as I've seen it in some of our 

> cells. The question is, is the wide metal next to small metal okay 

> in some cases? 
> 

>item 2> notch filling. The current notch filling algorithms will only 

> fill notch areas which do _not_ have connecting layers above or below 

> crossing into or totally inside the notch area. This is to prevent 

> shorts from occuring. Because routing in via layers is legal and 

> the spacing is only 5 udrs from via to metal (or metal to via) , and 

> notches can go the entire width of the chip, we cannot property 

> determine if all of the via crossing into the notch is electrically 

> connected. Thus the notch algorithm will not put metal over the 

> connecting layer. This could in fact create smaller notches and 

> even small holes (holes as small as 8 x 24 udrs) . However, notches 

> which no interactions with other layers will ge filled, only notches 

> which have some interaction with the connection layer will have parts 

> of that notch left open. The notch filling could create min spaces 

> from wide metals to narrow metals. Question is, do we still want 

> to fill notches/holes (NOTE: we cannot tell the difference between 

> a notch and a hole) 
> 

>item 3) via growing. A review of the fractured data of sisyphus' contped 
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> layer revealed an edge pattern that was apparently not quite 

. > what was expected so no growing was performed on sisyphus. The 

> results of growing other via layers will look just like Sisyphus'' 

> contped layer. Question is, do we still want to do via growing? 
> 

>item 4) via waffling. Via waff line has added a level of complexity to 

> the backend synthesis not quite imagined. The generation of waffles 

> for vias (and contped) does make wafflizing the metals much more 

> difficult and in some cases quite impossible to accomplish. There 

> are going to be large areas where we cannot add any via waffles 

> because of the dense metal routing. The wafflization will then 

> create a layer which may have many large/ small low density areas 

> with many large/small densely waffled areas. By removing via 

> waffling, the back end synthesis becomes a known problem with 

> existing solutions and minimal amount of work to integrate into 

> the existing backend flow. I still don't have a back end waffle flow 

> for upper metals. I have not had enough time to work on it yet and 

> at my current rate of progress could take many more weeks. 

> In addition, we will have no way of verifying that the final back 

> end metal pattern has not created a massive short since the resulting 

> metal layers are far too large for any lvs tool to handle. We will 

> have to trust that mere humans have done it right. Very scary. 

> Question is, do we still allow via waffles? 
> 

>item 5) removal of small metal waffles. I ran some small tests on sisyphus 

> which removed small metall waffle bars (less than 1.5 x 1.5) . This 

> resulted in many large areas (11x18 microns) which had _no_ metal 

> waffle bars. If we had waffled vial2 (like we will on euterpe) , 

> then the number of small metal waffle bars removed would increase 

> by some amount resulting in even large areas with no waffle bars 

> added. We've now converted very dense metal layers into relativly 

> sparse layers which will fail the current metal density checks. 

> Question is, do we want to remove small metal waffle bars and create 

> large unwaffles areas in metals? 
> 

> 

>I would like to come to some resolution on these question rather 
>quickly so I know where to focus my efforts for the back end synthesis. 
> 

>Thanks , 
>Dave 


>Dave Van't Hof MicroUnity Systems Eng., inc. 255 Caspian Sunnyvale, CA 94089 
>vanthof ©microunity.com 1 4 08 734-8100 

>"I don't know the meaning of the word surrender! I mean, I know it, 
>I 1 m not dumb... just not in this context." The Tick to Thrackazog 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1408734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 


Exhibit C16 


Page 122 of 128 


Subject: 


Sent: 
To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Saturday, July 01, 1995 11:46 AM 
Tim B, Robinson 
wampler (Kurt Wampler) 
Re: Sisyphus tape out 


Tim B. Robinson writes: 

Is this in connection with the ring osc, or the reall calliope Ml? 

<I just noticed the subject line, which I think answers that J > 

Right- it's the sisyphus tape out. 

The results will be ready for shipment Monday (and already have Al and 
Paul's blessing to just ship out the tapes.) will you be available 
to review 

the paperwork on Monday? Kurt and I discussed sending an postscript file 
of the paperwork to you for your review if you were planning on working 
remotely that day. 

I was planning to be operating remotely Monday, but if there is no- one 
else there to authorize it I'll come in. To do it right, I really 
need to look at the tapes also, just to check the labelling etc. 

Yes. Actually Kurt had the novel idea of maybe scanning in the labels and then sending you 
the imagel I don't know if we could get our hands on the technology or not. . . 

I haven't been able to talk to Grant (as a back up) - 
he's been in a meeting. 

So I'm not sure if he'll be around on Monday. 

OK, what time do you expect them to be ready and to ship out? If 
grant, jessica, juli or lois are there I think any of them can OK it. 
If not, I need about an hour to get down. 


Tim 


Okay. I saw your mail about Lois being out. Maybe we can get Juli to do it. 


- thanks , 
hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr 

Saturday, July 01, 1995 2:37 PM 
vanthof (vant) 

geert (Geert Rosseel); vanthof (Dave Van't Hof) 

Re: forwarded message from Mail Delivery Subsystem 


vant wrote (on Sat Jul 1) : 


Tim B. Robinson writes: 


> 


> 


>Must have been a typo here ... 

That's okay. I did get the message from the pollux alias. My latest release 
of layouts for pollux just finished and I wont be doing any more work on this 
until late tonight. 

so a new getbom can be done at any time if Tom has not done the tar tape 
yet. 

OK. I'll pick it up as soon as the make get's poast the current step. 


Tim 
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From: vanthof (vant) 

Sent: Saturday, July 01, 1995 2:25 PM 

To: Tim B. Robinson 

Cc: vanthof (Dave Van't Hof); geert (Geert Rosseel) 

Subject: Re: forwarded message from Mail Delivery Subsystem 


Tim B . Robinson writes: 


>Must have been a typo here ... 

That's okay. I did get the message from the pollux alias. My latest release of layouts 
for pollux just finished and I wont be doing any more work on this until late tonight. 

so a new getbom can be done at any time if Tom has not done the tar tape yet. 

Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1408734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . ■ The Tick to Thrackazog 
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Subject: 


Sent: 

To: 

Cc: 


From: 


for 

Saturday, July 01, 1995 2:23 PM 
vanthof (vant) 

pollux; torn (Tom Laidig); vanthof (Dave Van't Hot) 
Re: Another mobimos drc flow release 


vant wrote (on Sat Jul 1} : 

Tim B. Robinson writes: 
> 

>vant wrote (on Sat Jul 1) : 

> 

> they are most likely valid, as I believe I've now reduced the number of false 

> errors to a minimum. However, I made several edits to many cells late last 

> night and early this morning, then restarted all module drc runs. Only 

> mod8, 11, and 12 are left to finish up. Here are the current stats: 
> 

>Does this mean that the proteus snapshot bom I got last night in 

preparation for tom's tar copy for pollux is invalid? 

> 

>I took BOM 5.1525 and I see we are now at BOM 5.1527 

Yes, I'm afraid so. I made many edits to several cells for pollux. I was 
not able to completely clean them up, so there will be more edits over the 
weekend. Tom is out at the moment, so another getbom would catch things 
before his tar tape, unless of course, he has already comlpeted the tar. 

No, he's waiting on the make to complete. I'll kill it, get the new bom and restart. 


Tim 


Exhibit C16 


Page 126 of 12 


Sent: 
To: 

Cc: 


Subject: 


From: 


tbr 

Saturday, July 01 , 1995 2:21 PM 
hopper (Mark Hofmann) 
wampier (Kurt Wampler) 
sisyphus tape out 


Mark Hofmann wrote (on Fri Jun 30) : 


Hi Tim, 

We notice that we omitted to get rid of the MWAP layer over the cache 
area on the calliope baseplate. The result is that contped and metall did 
not get waffled in that area. Al is concerned that this large hole may 
peel and harm other active area. Therfore we are going to start a re- fracture 
of these 2 layers tonight. 

Is this in connection with the ring osc, or the reall calliope Ml? 

<I just noticed the subject line, which I thnk answers that J > 

The results will be ready for shipment Monday (and already have Al and 
Paul's blessing to just ship out the tapes.) will you be available to review 
the paperwork on Monday? Kurt and I discussed sending an postscript file 
of the paperwork to you for your review if you were planning on working 
remotely that day. 

I was planning to be operating remotely Monday, but if there is no-one else there to 
authorize it I'll come in. To do it right, I really need to look at the tapes also, just 
to check the labelling etc. 

I haven't been able to talk to Grant (as a back up)- he's been in a meeting. 
So I'm not sure if he'll be aroun don Monday. 

OK, what time do you expect them to be ready and to ship out? if grant, jessica, juli or 
lois are there I think any of them can OK it . 
If not, I need about an hour to get down. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Saturday, July 01, 1995 2:03 PM 
Tim B. Robinson 

pollux; torn (Tom Laidig); vanthof (Dave Van't Hof) 
Re: Another mobimos drc flow release 


Tim B. Robinson writes: 
> 

>vant wrote (on Sat Jul 1} : 
> 

> they are most likely valid, as I believe I've now reduced the number of false 

> errors to a minimum. However, I made several edits to many cells late last 

> night and early this morning, then restarted all module drc runs. Only 

> mod8, 11, and 12 are left to finish up. Here are the current stats: 

> 

>Does this mean that the proteus snapshot bom I got last night in 

preparation for tom's tar copy for pollux is invalid? 

> 

>I took BOM 5.1525 and I see we are now at BOM 5.1527 

Yes, I'm afraid so. I made many edits to several cells for pollux. I was not able to 
completely clean them up, so there will be more edits over the weekend. Tom is out at the 
moment, so another getbom would catch things before his tar tape, unless of course, he has 
already comlpeted the tar. 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 


Dave 
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